A commiton és a pullon túl: 3 hasznos Git parancs

A Git joggal az egyik legelterjedtebb verziókezelő, amely a felszínen sokszor egy nagyon egyszerű apró eszköznek tűnik, valójában azonban a Git meglehetősen komplex és kevesen vannak, akik otthonosak mozognak a szoftver funkciói között. Sőt mi több, sokunk a commit-push-pull szentháromságon kívül kevés parancsot ismer, így könnyen kitör a pánik, ha valami váratlan történik. Ebben a cikkben sem fogunk a lenézni Git legmélyebb bugyraiba, azonban ismertetünk néhány parancsot, amely a kezdők számára megkönnyítheti a mindennapi használatot.

Git Stash

Gyakran előfordul, hogy a jelenlegi munkádat félbe kell hagynod egy másik feladat kedvéért, és ezért branchet kell váltanod. A probléma persze az, hogy nem lenne szerencsés a félkész (potenciálisan működésképtelen) munkádat commitolni a jelenlegi branchbe csak amiatt, hogy később vissza tud hozni ezt az állapotot. Itt jön a képbe a git stash parancs.

A git stash parancs kiadásával a még nem commitált kód "eltűnik" anélkül, hogy commitálódott volna az akutális branchbe. Ez akár úgy is felfogható, mint egyfajta ideiglenes, lokális commit. A különbség, hogy a stash a committal ellentétben nem pusholható, kizárólag saját használatra létezik.

Amikor a másik branchben végeztél a munkáddal és átváltasz az eredetire, a git stash apply parancs kiadásával visszatérhetsz a korábbi állapothoz és folytathatod a heggesztést. Egy további hasznos parancs a git stash branch, amelynek segítségével egy stasht egy új branchben tudsz folytatni.

Git Reset

Ha egy commit után rájövünk, hogy hibát követtünk el, és szeretnénk visszavonni, a légkézenfekvőbb megoldás az ún. soft reset. Az utolsó commit a git reset --soft HEAD~1 paranccsal vonható vissza (korábbi commitig is visszavonhatjuk a változtatásokat a HEAD~n szintaxissal, ahol n a visszavonandó commitok száma).

A fő különbség a stash és a reset között, hogy míg a stash a félkész munka ideiglenes mentésére való, a reset a valódi, utólag észrevett hibák, vagy "véletlen" commitok visszavonására szolgál. Meg kell említetünk, hogy létezik hard reset is (git reset --hard), azonban ezzel bánjunk óvatosan — különösen ha pusholjuk a jelenlegi branchet —, mert ebben az esetben nincs mód a commit visszaállítására, az véglegesen törlődni fog.

Git Bisect

A git bisect akkor jön nagyon jól, ha felfedezünk a szoftverünkben egy bugot, és meg szeretnénk tudni, mikor jelent meg a kódbázisban először. Ez tulajdonképpen egy bináris kereséssel történik. A folyamat azzal kezdődik, hogy mutatunk a gitnek egy commitot, ahol a bug jelen van (ez az ún. bad commit, a példában legyen 364e91f3f268f0900bc3ee613f9f733e82aaed43), valahogy így:

git bisect start
git bisect bad 364e91f3f268f0900bc3ee613f9f733e82aaed43

A következő lépés, hogy visszarepülünk kicsit az időben, és gyorsan keresünk egy régi commitot, ahol a bug még nem jelentkezett. (Ez minél újabb, annál jobb, de nem kell túl sok energiát ölnünk a dologba, ha régi, hát régi.) Ha találtunk egy ilyen (good) commitot (legyen most a f0dfc4d5dc332d1cee34a634182e168c4efc3359), szintén mutassuk meg a gitnek:

git bisect good f0dfc4d5dc332d1cee34a634182e168c4efc3359

Ezután elkezdődik a bináris keresés, a git checkoutolja a két pont közti "középső" commitot. Ezt követően a mi dolgunk leellenőrizni, hogy ebben jelen van-e a vizsgált bug, és az eredménytől függően kiadjuk a git bisect good vagy a git bisect bad parancsot.

Ezt a folyamatot addig ismételjük, amíg a git meg nem találja az első rossz commitot. Ezután egy egyszerű git show-val meg tudjuk nézni a bugot első ízben előidéző változtatást.