Hogyan hozd helyre a Git repódat egy rosszul sikerült rebase után?

A Git az egyik legerősebb és legrugalmasabb verziókezelő rendszer, amelyet a szoftverfejlesztők használnak világszerte. Eszköztárának egyik legpotensebb, de egyben legveszélyesebb funkciója a git rebase. Képes tisztább commit előzményeket létrehozni, ami megkönnyíti a kód áttekintését és karbantartását. Azonban, mint minden erőteljes eszköz, a rebase is jár kockázatokkal. Egy rosszul sikerült rebase után könnyedén érezhetjük magunkat elveszettnek, mintha az összes munkánk a semmibe veszett volna. De ne aggódjon! Ez a cikk egy átfogó, részletes útmutatót nyújt arról, hogyan hozhatja helyre a Git repódat, még a legkomplikáltabb rebase balesetek után is. A legfontosabb: ne ess pánikba, mert a Git a legtöbb esetben képes visszaállítani a korábbi állapotot.

Miért is olyan „veszélyes” a Git rebase?

Mielőtt a helyreállítási stratégiákba merülnénk, értsük meg, miért is történnek ezek a balesetek. A git rebase lényegében újraírja a projekt előzményeit. Ahelyett, hogy egy egyszerű összevonást (merge) hajtana végre, ami egy új merge commitot hoz létre, a rebase a commitjaidat „átülteti” egy új alapra. Ez tisztább, lineárisabb történetet eredményez, de ezáltal a régi commitek identitása (hash-e) megváltozik. A leggyakoribb okok, amiért egy rebase félrecsúszhat:

Merge konfliktusok: Amikor a bázis (alap) és a rebase-elt ág ugyanazon a fájlon vagy sorokon változtatott, konfliktusok lépnek fel. Ezek manuális feloldása időigényes és hibalehetőségeket rejt.
Interaktív rebase (-i) hibák: A drop, squash, edit vagy reword parancsok rossz használata. Egy nem kívánt commit elhagyása (drop) vagy a commitek rossz sorrendbe rendezése könnyen okozhat fejfájást.
Erőltetett push (--force) megosztott ágra: A legveszélyesebb hiba. Ha valaki más már letöltötte a régi előzményeket, és Ön felülírja azokat a távoli repóban egy rebase-elt verzióval, az mások számára rendkívül zavaró és adatvesztést okozhat.
Elveszett commitek: Néha úgy érezhetjük, mintha a commitek egyszerűen eltűntek volna.

A Megmentő: `git reflog` – A Git Fekete Doboza

Amikor úgy tűnik, hogy minden elveszett, a git reflog parancs az első és legfontosabb eszköz a tarsolyunkban. Gondoljon rá úgy, mint a Git „fekete dobozára”. A git reflog (reference log) minden egyes alkalommal rögzíti, amikor a HEAD mutatója megváltozik a lokális repójában. Ez magában foglalja a commiteket, brancheket, reseteket, merge-eket és természetesen a rebase műveleteket is.

Hogyan működik a `git reflog`?

Amikor beírja a terminálba a git reflog parancsot (vagy a részletesebb git reflog show parancsot), egy listát kap a legutóbbi HEAD mozgásokról, időrendi sorrendben, a legújabbat mutatva legfelül. Minden bejegyzés tartalmazza:

A commit hash-ét, ahová a HEAD mutatott.
Az @{n} indexet (pl. HEAD@{0}, HEAD@{1}), amely az adott állapotra hivatkozik.
A művelet leírását (pl. commit, rebase: aborting, reset: moving to HEAD@{1}).

Például:

$ git reflog
a1b2c3d HEAD@{0}: rebase (finish): returning to refs/heads/my-feature
e4f5g6h HEAD@{1}: rebase (start): checkout origin/main
i1j2k3l HEAD@{2}: commit: Add new feature X
m4n5o6p HEAD@{3}: checkout: moving from main to my-feature
q7r8s9t HEAD@{4}: commit (initial): Initial commit

Láthatja, hogy a HEAD@{2} állapotban volt egy „Add new feature X” nevű commit. Ez az az állapot, amire valószínűleg vissza akarunk térni, ha a rebase után elvesztettük ezt a commitot.

Helyreállítási forgatókönyvek és megoldások

1. forgatókönyv: Rebase folyamatban van, konfliktus vagy hiba történt

Ez a legkevésbé fájdalmas forgatókönyv. Ha egy rebase közben konfliktusba ütközik, vagy egyszerűen rájön, hogy nem ezt akarta, még mielőtt a git rebase --continue parancsot futtatta volna, könnyedén visszatérhet az eredeti állapotba.

Megoldás:

git rebase --abort

Ez a parancs azonnal leállítja a rebase folyamatot, és visszaállítja az ágat arra az állapotra, amiben a rebase megkezdése előtt volt. Minden módosítás, amit a rebase során eszközölt volna, eltűnik, és az ág (branch) pontosan olyan lesz, mint a parancs kiadása előtt. Ez a leggyorsabb menekülési útvonal.

2. forgatókönyv: Rebase befejeződött, de a lokális repóban káosz van

Ez az egyik leggyakoribb és legijesztőbb eset: a rebase lefutott, de az előzmények rosszak, commitek tűntek el, vagy egyszerűen csak nem úgy alakult, ahogy szerette volna. Mivel még nem tette meg a változtatásokat a távoli (remote) repóban, még van ideje csendben, egyedül rendet rakni.

Megoldás (a git reflog és git reset --hard használatával):

Keresse meg a „jó” állapotot a git reflog segítségével:
Futtassa a git reflog parancsot, és gondosan vizsgálja meg a kimenetet. Keresse meg azt a bejegyzést, ami közvetlenül a rebase megkezdése előtt történt. Ez általában egy commit vagy checkout művelet lesz, ami a régi HEAD állapotára mutat. Jegyezze fel a hozzá tartozó commit hash-ét (pl. i1j2k3l) vagy a HEAD@{n} referenciát (pl. HEAD@{2}).
Mentse el a változtatásokat (opcionális, de erősen ajánlott):
Ha vannak nem commitolt változtatásai, vagy attól tart, hogy elveszít valamit, használja a git stash parancsot:
```
git stash save "Mielőtt a rossz rebase-t javítanám"
```
Ez megóvja a munkafolyamatban lévő, de még nem commitolt módosításokat.
Állítsa vissza az ágat a kiválasztott állapotra:
Most jön a lényegi lépés. Használja a git reset --hard parancsot a megtalált „jó” commit hash-ével vagy HEAD referenciával. Például:
```
git reset --hard i1j2k3l
```
vagy
```
git reset --hard HEAD@{2}
```
FIGYELEM: A git reset --hard parancs visszaállítja az ágat a megadott commitra, és ELVETI az összes nem commitolt változtatást, valamint az összes commitot, ami a céldátum után történt. Ezért fontos a stashelés, ha van mentetlen munkája.
Ellenőrizze az ágat:
Futtasson egy git log --oneline parancsot, és győződjön meg róla, hogy az ág a kívánt állapotban van.

Gratulálunk! Sikeresen visszaállította az ágát a rebase előtti állapotba. Most újra próbálkozhat a rebase-zel, vagy választhat egy másik megközelítést.

3. forgatókönyv: Rebase befejeződött, commitek estek ki az interaktív rebase során

Ha interaktív rebase (git rebase -i) során véletlenül drop-olt egy commitot, vagy rosszul rendelte a commiteket, a git reflog ismét a barátja.

Megoldás (git reflog és git cherry-pick használatával):

Keresse meg az elveszett commit hash-ét a git reflog segítségével:
Futtassa a git reflog parancsot, és próbálja meg azonosítani az elveszett commitot a commit üzenete alapján. Mivel az interaktív rebase alapvetően új commiteket generál, az elveszett commit eredeti hash-ét a rebase *előtti* HEAD mozgások között kell keresni. Jegyezze fel az elveszett commit eredeti hash-ét.
Hozza vissza a commitot:
Navigáljon az ágon arra a pontra, ahol a commitot be szeretné illeszteni (pl. git checkout my-feature-branch). Ezután használja a git cherry-pick parancsot a megtalált commit hash-ével:
```
git cherry-pick <elveszett_commit_hash>
```
Ez a parancs újra alkalmazza az adott commit változásait az aktuális ágra, mintha egy új commitként került volna be. Ezt többször is megteheti, ha több commitot vesztett el.

4. forgatókönyv: Rebase befejeződött és a távoli (remote) repóba is erőltetve lett pusholva

Ez a legbonyolultabb és potenciálisan legkárosabb forgatókönyv, különösen ha egy megosztott ágon történt, amin mások is dolgoznak. Alapvető szabály: soha ne használja a git push --force parancsot egy megosztott ágon, ha nem tudja pontosan, mit csinál, és nem egyeztetett a csapattal! Mindig a git push --force-with-lease parancsot részesítse előnyben, mivel ez biztonságosabban ellenőrzi, hogy a távoli ág nem változott-e meg azóta, hogy Ön letöltötte.

Ha mégis megtörtént a baj:

Azonnali kommunikáció:
Ez a legfontosabb lépés. Értesítse a csapatát, hogy egy „rossz” force push történt, és kérje meg őket, hogy NE húzzák le a távoli ágat (vagy ha már megtették, ne dolgozzanak rajta), amíg a probléma meg nem oldódik.
Helyreállítási lehetőségek (választás a helyzettől függően):
- Ha Ön az egyetlen, aki dolgozik az ágon (vagy azonnal elkapta a hibát):
  A 2. forgatókönyvnél leírt módon állítsa helyre a lokális ágát a kívánt állapotra (git reflog és git reset --hard <jó_állapot>). Ezután, ha meggyőződött róla, hogy minden rendben van, használja a git push --force-with-lease parancsot (vagy ha tudja, hogy senki sem nyúlt az ághoz, akkor a git push --force-t) a távoli ág felülírására a helyes előzményekkel.
- Ha mások már dolgoztak a felülírt ágon:
  Ez nehézkes. A legjobb megoldás általában az, ha Ön a git reflog segítségével visszaállítja a lokális ágát a jó állapotra, majd git revert parancsokkal visszavonja a rosszul rebase-elt commiteket, amelyek esetleg bekerültek a távoli ágra. Alternatívaként a csapat tagjainak is végig kell menniük a git reflog és git reset --hard origin/<ág_neve> lépéseken, hogy ők is visszaállítsák a lokális repóikat, majd újra kell húzniuk a helyes ágat. Ez a forgatókönyv bonyolultabb és általában csapatmunka révén oldható meg a legjobban. Kerülje el, ha lehetséges!

5. forgatókönyv: Elveszett Stash

Előfordulhat, hogy egy rebase közben elveszít egy stasht. Bár ritka, ha mégis megtörténik, a Git rendelkezik mechanizmusokkal a helyreállításra.

Megoldás:

git stash list:
Először is győződjön meg róla, hogy tényleg elveszett. A git stash list kilistázza az összes stasht.
git reflog stash:
Ha a git stash list nem mutatja, de emlékszik a stash időpontjára, próbálja meg a git reflog stash parancsot. Ez az összes stash műveletet kilistázza, és segítségével megtalálhatja az elveszett stasht. Amint megtalálta a hash-ét (pl. stash@{2}), alkalmazhatja azt a git stash apply stash@{2} paranccsal.
git fsck --lost-found (haladó):
Ez egy mélyebb szintű parancs, amely megkeresi a „lebegő” (dangling) objektumokat a Git adatbázisában, amelyek lehetnek commitek, fájlok vagy stashek. Ezt csak akkor használja, ha a fentiek nem működtek. Ez a parancs egyedi hash-eket ad vissza, amelyeket aztán megvizsgálhat (pl. git show <hash>), hogy azonosítsa az elveszett tartalmat.

Megelőzés: Jobb a bajt elkerülni, mint helyrehozni

Bár a Git a helyreállításban zseniális, a legjobb stratégia mindig a megelőzés. Íme néhány tipp, hogy elkerülje a rebase okozta fejfájásokat:

Commitoljon gyakran és kicsi adagokban: Így ha valami elromlik, könnyebb lesz visszatérni egy korábbi stabil pontra.
Készítsen biztonsági másolatot az ágáról: Mielőtt egy nagyobb rebase-t hajtana végre, hozzon létre egy ideiglenes backup ágat:
```
git branch my-feature-backup
```
Ha valami félresikerül, egyszerűen visszatérhet ehhez az ághoz.
Mindig használja a git push --force-with-lease parancsot: Soha ne használja a sima git push --force parancsot, hacsak nem biztos abban, hogy a távoli ág nem változott meg azóta, hogy Ön letöltötte. A --force-with-lease sokkal biztonságosabb, mert ellenőrzi ezt az állapotot.
Ismerje meg a git rebase parancsot: Gyakoroljon egy „játszó” repóban, mielőtt éles környezetben használná. Értse meg az -i (interaktív) mód működését.
Soha ne rebase-eljen megosztott ágakat: Ha az origin/main vagy origin/develop ágakat rebase-eli, garantáltan problémákat okoz a csapatnak.

Haladó tippek és eszközök

Néhány Git GUI eszköz (pl. Sourcetree, GitKraken, VS Code Git integráció) vizuálisan megjelenítheti a git reflog kimenetét és a commit előzményeket, ami sokat segíthet a jó állapot azonosításában és a helyreállításban. Ezek az eszközök gyakran egyszerűbbé teszik a cherry-pick és a reset műveleteket is.

Összegzés

A git rebase egy rendkívül hasznos, de összetett parancs. A hibák elkerülhetetlenek, de a Git robusztus felépítésének köszönhetően a legtöbb rebase balesetből van kiút. A legfontosabb, hogy megőrizze a hidegvérét, és tudja, hogy a git reflog a legjobb barátja a Git helyreállításában. Ne feledje, minden hiba egy tanulási lehetőség, és minden sikeres helyreállítás csak megerősíti a Git-tudását. Gyakoroljon, legyen óvatos, és ne féljen használni a Git erőteljes eszközeit!