Amikor megtanul kódolni, előbb-utóbb megismeri a verziókezelő rendszereket is. És bár sok versengő eszköz van ezen a téren, az egyik a de facto szabvány, amelyet az ipar szinte mindenki használ. Olyan népszerű, hogy vannak olyan vállalatok, amelyek márkanevükben használják a nevét. Természetesen Gitről beszélünk.

Míg a Git egy hatalmas eszköz, ereje jól el van rejtve. Van néhány alapvető fogalom, amelyet meg kell értened ahhoz, hogy igazán jártas legyél a Gitnél. A jó hír az, hogy ha egyszer megtanulod őket, aligha fogsz olyan bajba kerülni, amely elől nem tudsz elmenekülni.

A tipikus munkafolyamat

Egy tipikus Git munkafolyamatban helyi adattárat, távoli adattárat és egy vagy több ágat fog használni. Az adattárak a projekttel kapcsolatos összes információt tárolják, beleértve annak teljes történetét és az összes ágat. A fióktelep alapvetően egy üres projektből a jelenlegi állapotba vezető változások gyűjteménye.

A lerakat klónozása után a helyi példányon dolgozik, és új módosításokat vezet be. Amíg nem hajtja végre a távoli adattár helyi változtatásait, addig minden munkája csak a számítógépén érhető el.

Amikor befejezi a feladatot, ideje szinkronizálni a távoli adattárral. Húzza a távoli módosításokat, hogy lépést tudjon tartani a projekt előrehaladásával, és a helyi változtatásokat szeretné megossza, hogy megossza munkáját másokkal.

Helyi változások

Minden rendben van, ha Ön és a csapat többi tagja teljesen különálló fájlokon dolgozik. Bármi is történik, nem fogtok egymás lábára lépni.

Vannak azonban esetek, amikor Ön és csapattársai egyszerre vezetnek be változásokat ugyanazon a helyen. És általában ott kezdődnek a problémák.

Kivégeztél valaha git pull, hogy csak a rettegetteket láthasd error: Your local changes to the following files would be overwritten by merge:? Előbb vagy utóbb mindenki belefut ebbe a problémába.

Ami itt zavaróbb, hogy nem akar összeolvadni semmit, csak húzza, igaz? Valójában a pull valamivel bonyolultabb, mint gondolnád.

Mennyire működik pontosan a Git Pull?

A húzás nem egyetlen művelet. Ez abból áll, hogy adatokat tölt le a távoli szerverről, majd egyesíti a módosításokat a helyi adattárral. Ez a két művelet manuálisan is végrehajtható, ha akarja:

git fetch git merge origin/$CURRENT_BRANCH

A origin/$CURRENT_BRANCHrész azt jelenti, hogy:

• A Git egyesíti a változtatásokat a nevezett távoli adattárból origin(amelyből klónoztál)
• amelyek hozzáadódtak a $CURRENT_BRANCH
• amelyek még nincsenek meg a helyi kijelölt fiókban

Mivel a Git csak akkor hajt végre összevonásokat, ha nincsenek elkötelezett módosítások, minden alkalommal, amikor nem elkötelezett módosításokkal fut git pull, bajba kerülhet. Szerencsére vannak módok arra, hogy egy darabban kikerüljenek a bajból!

Különböző megközelítések

Ha még nem hajtott végre helyi változtatásokat, és mégis új verziót szeretne letölteni a távoli kiszolgálóról, akkor a felhasználási esete általában a következő esetek egyikébe esik. Bármelyik:

• nem törődsz a helyi változásokkal, és felül akarod írni őket,
• nagyon érdekel a változások és a távoli változtatások után szeretné alkalmazni őket,
• le szeretné tölteni a távoli módosításokat, de még nem alkalmazza azokat

Mindegyik megközelítés más és más megoldást igényel.

Nem érdekel a helyi változások

Ebben az esetben csak el akarja dobni az összes nem végrehajtott helyi változtatást. Talán módosított egy fájlt a kísérlethez, de már nincs szüksége a módosításra. Csak az érdekel, hogy naprakész legyél az upstream-szel.

Ez azt jelenti, hogy még egy lépést kell tennie a távoli változtatások beolvasása és egyesítése között. Ez a lépés visszaállítja az ágat módosítatlan állapotába, ezáltal lehetővé téve git mergea munkát.

git fetch git reset --hard HEAD git merge origin/$CURRENT_BRANCH

Ha nem szeretné, hogy írja be a fiók neve minden alkalommal ezt a parancsot, Git egy szép parancsikont mutatva, hogy az upstream ág: @{u}. Az upstream ág a távoli adattár azon ága, amelyhez nyomul, és ahonnan letölti.

A fenti parancsok így néznének ki a parancsikon segítségével:

git fetch git reset --hard HEAD git merge '@{u}'

A példában hivatkozunk a parancsikonra, hogy megakadályozzuk a shell értelmezését.

Nagyon törődik a helyi változásokkal

Amikor az el nem hajtott módosításai jelentősek számodra, két lehetőség áll rendelkezésre. Kötelezheti őket, majd elvégezheti git pull, vagy elrejtheti őket.

A stagnálás azt jelenti, hogy a változásokat egy pillanatra eltesszük, hogy később visszahozzuk őket. Pontosabban: git stashlétrehoz egy olyan kötelezettségvállalást, amely nem látható az aktuális ágon, de mégis elérhető a Git által.

Az utolsó tároláskor elmentett változtatások visszahozásához használja a git stash popparancsot. Miután sikeresen alkalmazta az elrejtett módosításokat, ez a parancs eltávolítja a rejtett műveletet is, mivel erre már nincs szükség.

A munkafolyamat ekkor nézhet ki:

git fetch git stash git merge '@{u}' git stash pop

Alapértelmezés szerint a tárolásból származó változások szakaszossá válnak. Ha le akarja állítani őket, használja a parancsot git restore --staged(ha a 2.25.0-nál újabb Git-et használja).

Csak le szeretné tölteni a távoli módosításokat

Az utolsó forgatókönyv kissé eltér az előzőektől. Tegyük fel, hogy egy nagyon rendetlen refaktorálás kellős közepén vagy. Sem a változások elvesztése, sem elrablása nem lehetséges. Mégis szeretné, hogy a távoli változtatások elérhetők legyenek, hogy fussanak git diffvelük.

Amint valószínűleg rájöttél, a távoli változtatások letöltéséhez egyáltalán nincs szükség git pull! git fetchéppen elég.

One thing to note is that by default, git fetch will only bring you changes from the current branch. To get all the changes from all the branches, use git fetch --all. And if you'd like to clean up some of the branches that no longer exist in the remote repository, git fetch --all --prune will do the cleaning up!

Some Automation

Have you heard of Git Config? It's a file where Git stores all of the user-configured settings. It resides in your home directory: either as ~/.gitconfig or ~/.config/git/config. You can edit it to add some custom aliases that will be understood as Git commands.

For example, to have a shortcut equivalent to git diff --cached (that shows the difference between the current branch and the staged files), you'd add the following section:

[alias] dc = diff --cached

After that, you can run git dc whenever you wish to review the changes. Going this way, we can set up a few aliases related to the previous use cases.

[alias] pull_force = !"git fetch --all; git reset --hard HEAD; git merge @{u}" pf = pull_force pull_stash = !"git fetch --all; git stash; git merge @{u}; git stash pop"

This way, running git pull_force will overwrite the local changes, while git pull_stash will preserve them.

The Other Git Pull Force

Curious minds may have already discovered that there is such a thing as git pull --force. However, this is a very different beast to what's presented in this article.

It may sound like something that would help us overwrite local changes. Instead, it lets us fetch the changes from one remote branch to a different local branch. git pull --force only modifies the behavior of the fetching part. It is therefore equivalent to git fetch --force.

Like git push, git fetch allows us to specify which local and remote branch do we want to operate on. git fetch origin/feature-1:my-feature will mean that the changes in the feature-1 branch from the remote repository will end up visible on the local branch my-feature. When such an operation modifies the existing history, it is not permitted by Git without an explicit --force parameter.

Just like git push --force allows overwriting remote branches, git fetch --force (or git pull --force) allows overwriting local branches. It is always used with source and destination branches mentioned as parameters. An alternative approach to overwriting local changes using git --pull force could be git pull --force "@{u}:HEAD".

Conclusion

Git világa hatalmas. Ez a cikk csak a tároló karbantartásának egyik aspektusát fedte le: a távoli változtatások beépítését egy helyi adattárba. Még ez a mindennapi forgatókönyv is megkövetelte, hogy kicsit mélyebben tanulmányozzuk ennek a verziókezelő eszköznek a belső mechanizmusait.

A tényleges használati esetek elsajátítása segít jobban megérteni, hogyan működik a Git a motorháztető alatt. Ez pedig felhatalmazva fogja érezni magát, valahányszor bajba kerül. Mindannyian időről időre megtesszük.