A commiton és a pullon túl II.: További hasznos Git parancsok

Az előző blogunkban megnéztünk néhány Git parancsot, amelyek megkönnyíthetik a teljesen kezdők életét. Ma folytatjuk sorozatunkat, és ismertetünk két másik opciót, amik nagyban növelhetik a hatékonyságodat a Gittel való munka során.

Git Rebase

Sokszor hallani, hogy a git rebase valami olyan varázslat, amelytől jobb, ha a kezdők távoltartják magukat, de ha okosan használjuk, jó szolgálatot tehet.

Ha nem ismered jól ezt a parancsot, a legfontosabb talán azt megjegyezni, hogy a git rebase és a git merge (amelyet a legtöbben bizonyára ismertek már) ugyanazt a célt szolgálja, vagyis két branch változtatásait egyesítik, de a módszer meglehetősen különböző a két esetben. Míg a mergenél a két branch változtatásait úgy egyesítjük, hogy egy ún. merge committal az egyik branchbe integráljuk a másik változtatásait, ezzel szemben a rebase a branch történetét megváltoztatva alkalmazza a másik branchben történt változtatásokat a jelenlegiben.

A merge előnye, hogy nem változtat a meglévő brancheken, hátránya viszont, hogy a mellékbranch történetében minden alkalommal, amikor beolvasztjuk a fő branch változtatásait, zavaró merge commitok keletkeznek.

A rebase művelet esetén a mellékbranch kezdőpontját a főbranch végpontjához mozgatjuk, és ismételten végrehatjuk az ott történt változtatásokat, ezzel teljesen új commitokat létrehozva. A rebase fő előnye, hogy sokkal letisztultabb historyt ad (nincsenek merge commitok), és a projekt története teljesen lineáris lesz, nincsenek elágazások, kizárólag a master branch legvégén.

A művelet hátránya, hogy kevéssé követhető (merge commitok hiányában nem látjuk pontosan, mikor kerültek a fő branch változtatásai a mellékbranchbe). Emellett akár katasztrofális következményei is lehetnek, ha nem tartunk egy fontos szabályt: a git rebase műveletet sosem használjuk publikus branchen! Ez azért fontos, mert ilyenkor a többi fejlesztő még mindig az eredeti branchen fog dolgozni, a Git pedig úgy fogja értelmezni a szituációt, mintha a te branched története egy ponton elvált volna mindenki másétól. Szóval mielőtt végrehajtunk egy git rebase-t, mindig gondoljuk át, hogy valaki más is használja-e a kiszemelt branchet!

Git Cherry-Pick

A git cherry-pick egy ritkábban használt parancs, de sokszor jól jöhet. Alapvetően ez a művelet egy tetszőlegesen kiválasztott, múltbéli commit változtatásait alkalmazza a jelenlegi branchre.

Fontos megjegyezni, hogy mivel a gitben egy commit azonosítóját a változtatás tartalma és kezdőpontja együttesen határozza meg, a git cherry-pick egy teljesen új commitot fog létrehozni, hiába ugyanazt a változtatást alkalmazzuk.

Git Fixup

Képzeljük el azt a mindennapi szituációt, amikor egymás után fejlesztünk le két változtatást, legyenek ezek A és B. Néhány fájl módosítása után elkészültünk az elsővel, így a szokásos módon csinálunk egy commitot:

git commit -m "Az A valtoztatas elkeszult!"

Folytatjuk a munkát, ezúttal a B változtatáson dolgozunk, ezzel hamar végzünk is, és ismét commitolunk:

git commit -m "A B valtoztatas elkeszult!"

Ekkor azonban rájövünk, hogy valamit elfelejtettünk az A változtatás során, így gyorsan kijavítjuk, és újra commitálunk egy "Fix A" üzenettel. Ezután a history valahogy így néz ki:

fe4da2a Az A valtoztatas elkeszult!
ac6dc87 A B valtoztatas elkeszult!
743e6ff Fix A

Letisztultabbá tehetjük a commitok történetét, ha az utolsó javítást a git commit --fixup ac6dc87 paranccsal végezzük el, így jelezve, hogy ez egy korábbi commit javítása. Ezután ha végrehajtunk például egy rebase-t később, a Git összevonja a fixup commitot az eredetivel, eltüntetve így a "szemetelő" változtatást.