Hogyan vonj vissza egy commitot a Gitben?

Képzeljük el a helyzetet: órákig dolgoztunk egy új funkción, mindent szépen összeraktunk, majd a nagy rohanásban bekövetkezik a baj. Elkövetünk egy commitot, amibe bekerül egy hiba, egy felesleges fájl, vagy ami még rosszabb, érzékeny adat. Vagy talán rájövünk, hogy az utolsó néhány commit rossz irányba viszi a projektet, és vissza kellene fordulni. Ne essünk kétségbe! A Git, ez a hihetetlenül erős verziókezelő rendszer, szerencsére számos eszközt kínál az ilyen esetek kezelésére. Ebben az átfogó útmutatóban lépésről lépésre végigvezetjük Önt azon, hogyan vonhat vissza egy commitot a Gitben, a különböző forgatókönyvek figyelembevételével.

Miért kellhet visszavonni egy commitot?

Mielőtt mélyebben belemerülnénk a technikai részletekbe, értsük meg, miért is olyan fontos tudni, hogyan kezeljük a Git előzményeit. Íme néhány gyakori ok:

Hibás kód bekerülése: Egy commit tartalmaz egy bugot, ami megakadályozza az alkalmazás működését.
Felesleges vagy ideiglenes fájlok: Véletlenül committeltünk egy .env fájlt, logokat, vagy más, verziókezelés szempontjából irreleváns adatot.
Rossz irányú fejlesztés: Két-három commit után rájövünk, hogy az aktuális fejlesztési irány téves, és jobb lenne visszatérni egy korábbi állapothoz.
Szemantikai hibák: Hibás commit üzenet, rossz szerzői adatok.
Sürgős javítások: Egy éles rendszeren felmerülő hiba miatt gyorsan vissza kell állítani egy korábbi, stabil verziót.

A jó hír az, hogy a Git rendkívül rugalmas. Számos eszközt biztosít a „tévedések” korrigálására, anélkül, hogy elveszítenénk a munkánkat. Fontos azonban megérteni a különbségeket a parancsok között, és azt, hogy mikor melyiket érdemes használni, különösen, ha már megosztottuk a munkánkat másokkal.

A Git filozófiája: Az előzmények szentsége

Mielőtt bármit tennénk, fontos megérteni a Git egyik alapvető filozófiáját: az előzmények (history) szinte „szentek”. A Git úgy épült fel, hogy minden változást rögzítsen, és ezeket a változásokat alapvetően nem törli. Amikor „visszavonunk” egy commitot, általában nem töröljük azt véglegesen, hanem létrehozunk egy új commitot, ami visszafordítja a korábbi változtatásokat, vagy átírjuk az előzményeket, de még ekkor is megmarad egy lehetőség a visszaállításra a Git reflog segítségével.

Ez a megközelítés garantálja az adatok integritását és a nyomon követhetőséget. A kulcs az, hogy tudjuk, melyik parancsot mikor használjuk, figyelembe véve, hogy a commit már megosztott-e másokkal (pl. feltöltöttük egy távoli szerverre, mint a GitHub, GitLab, Bitbucket), vagy még csak a helyi repositorynkban létezik.

1. A biztonságos út: `git revert`

A git revert az a parancs, amit akkor érdemes használni, ha egy már publikált, megosztott commitot szeretnénk visszavonni. Ennek oka, hogy a git revert nem írja át az előzményeket. Ehelyett létrehoz egy új commitot, ami pontosan visszafordítja a megadott commitban történt változtatásokat. Így az eredeti (hibás) commit továbbra is része marad az előzményeknek, de a projekt állapota visszatér a kívánt állapotba.

Mikor használjuk a `git revert`-et?

Ha a commit már feltöltésre került egy távoli repositoryba (pl. origin/main), és mások már letöltötték vagy továbbfejlesztették azt.
Ha fontos, hogy az előzmények lineárisak és átláthatóak maradjanak, minden egyes változtatás (és annak visszavonása) rögzítve legyen.
Ha nem akarunk senki más munkájába beleavatkozni egy force push-sal.

Hogyan használjuk a `git revert`-et?

Először is, azonosítanunk kell annak a commitnak a hash-ét (azonosítóját), amelyet vissza szeretnénk vonni. Ezt megtehetjük a git log paranccsal:

git log --oneline

Ez egy tömörített listát ad a commitokról, melyek elején látható a rövid hash. Tegyük fel, hogy a visszavonandó commit hash-e abcdef1.

A visszavonás parancsa a következő:

git revert abcdef1

Miután kiadtuk a parancsot, a Git alapértelmezés szerint megnyitja a konfigurált szövegszerkesztőnket, hogy lehetőséget adjon a revert commit üzenetének módosítására. Az alapértelmezett üzenet általában „Revert „[eredeti commit üzenet]””, ami tökéletesen megfelel a legtöbb esetben. Mentés és bezárás után a Git létrehozza az új commitot.

Gyakori opciók és forgatókönyvek:

-n vagy --no-commit: Ez az opció lehetővé teszi, hogy a visszavonás megtörténjen, de a Git ne hozza létre automatikusan a commitot. A változások a munkakönyvtárban (working directory) és a staging area-ban fognak megjelenni, készen arra, hogy manuálisan módosítsuk, mielőtt committeljük őket. Ez hasznos, ha több commitot szeretnénk „összegyúrni” egyetlen revert commitba, vagy ha finomhangolni akarjuk a visszavonás eredményét.
```
git revert -n abcdef1
```
Több commit visszavonása egyszerre: Visszavonhatunk több egymást követő commitot is. A Git fordított sorrendben alkalmazza a revert commitokat, így a legkorábbi commitot vonja vissza először.
```
git revert <earliest-commit-hash>^..<latest-commit-hash>
```
A ^ jel a megadott commit előtti commitra utal, így a fenti parancs az earliest-commit-hash utáni összes commitot visszafordítja, beleértve a latest-commit-hash-t is.

Előnyök és hátrányok:

Előnyök: Biztonságos megosztott repositorykban, nem írja át az előzményeket, könnyen visszacsinálható.
Hátrányok: Az előzmények „zajosabbá” válhatnak, ha sok revert commitot alkalmazunk, mivel minden visszavonás egy új commitot jelent.

2. Az előzményeket átíró út: `git reset`

A git reset egy sokkal erőteljesebb parancs, amely „átírja” az előzményeket. Ez azt jelenti, hogy a Git repositorynk története megváltozik, mintha a commitek soha nem is léteztek volna. Ezért a git reset-et csak akkor használjuk, ha a commitek még nem kerültek publikálásra egy távoli repositoryba, és mások nem alapozzák rá a munkájukat. Ha megosztott repositoryn használjuk, komoly konfliktusokat okozhat.

Mikor használjuk a `git reset`-et?

Ha a commitok még csak a helyi repositorynkban léteznek.
Ha szeretnénk teljesen eltüntetni a hibás commitot az előzményekből.
Ha több apró commitot szeretnénk „összegyúrni” egyetlen értelmes commitba (interaktív rebase-szel kombinálva).

A `git reset` típusai:

A git reset három fő módban működhet, amelyek mindegyike másképp befolyásolja a munkakönyvtárat és a staging area-t:

a) `git reset --soft <commit-hash>`

Mit tesz: Ez a parancs a HEAD mutatót a megadott commitra állítja vissza, de a változtatásokat a staging area-ban (indexben) hagyja. Ez azt jelenti, hogy a visszavont commitok összes módosítása továbbra is „színre készen” várja, hogy újracommíteljük.
Mikor használjuk: Akkor, ha vissza akarunk vonni egy commitot, de meg akarjuk tartani az összes változást a staging area-ban, hogy újra commíteljük, például egy jobb üzenettel, vagy egy másik commitba vonva össze.

git reset --soft HEAD~1

(Ez az utolsó commitot vonja vissza, a változások az indexben maradnak.)

b) `git reset --mixed <commit-hash>` (Ez az alapértelmezett, ha nem adunk meg opciót)

Mit tesz: A HEAD mutatót a megadott commitra állítja, és a változásokat a munkakönyvtárba helyezi, de eltávolítja őket a staging area-ból. Ezáltal a módosítások a „not staged for commit” állapotba kerülnek.
Mikor használjuk: Ez a leggyakoribb beállítás, ha vissza akarunk lépni egy korábbi állapotba, de meg akarjuk tartani a változásokat a munkakönyvtárban, hogy újra átgondoljuk, módosítsuk, és majd ismét manuálisan hozzáadjuk a staging area-hoz, mielőtt újra commítelnénk.

git reset HEAD~2

(Ez az utolsó két commitot vonja vissza, a változások a munkakönyvtárban maradnak, nincsenek az indexben.)

c) `git reset --hard <commit-hash>` – RENDKÍVÜL ÓVATOSAN HASZNÁLJUK!

Mit tesz: Ez a parancs a HEAD mutatót a megadott commitra állítja, és ami a legfontosabb, TELJESEN ELDOBJA a visszavont commitekben lévő ÖSSZES változást a munkakönyvtárból és a staging area-ból egyaránt. Az elveszett adatok ilyenkor már nincsenek sehol (kivéve a reflogban egy ideig).
Mikor használjuk: Csak akkor, ha teljesen biztosak vagyunk benne, hogy a visszavont commitekben lévő változásokra semmi szükségünk, és el akarjuk őket felejteni. Ideális, ha egy „piszkos” kísérletezés után szeretnénk visszatérni egy tiszta állapotba.

git reset --hard HEAD~3

(Ez az utolsó három commitot vonja vissza, az összes változás ELVÉSZ! A munkakönyvtár is a kiválasztott commit állapotát tükrözi.)

Fontos megjegyzés a `git reset` és a távoli repositoryk kapcsán:

Ha egy git reset paranccsal átírtuk a helyi repositorynk előzményeit, és megpróbáljuk feltölteni a változásokat egy távoli repositoryba (pl. git push), a Git valószínűleg hibát fog jelezni, mert a helyi előzmények eltérnek a távoliaktól. Ilyenkor a git push --force vagy git push --force-with-lease parancsra lehet szükség. A git push --force parancs rendkívül veszélyes, mert felülírja a távoli repository előzményeit a helyiekkel, ezzel potenciálisan mások munkáját írhatja felül vagy törölheti! Mindig győződjünk meg róla, hogy tudjuk, mit csinálunk, és kommunikáljunk a csapatunkkal, mielőtt force push-t alkalmaznánk egy megosztott ágon.

3. Az elveszett commitek megmentője: `git reflog`

Még ha a git reset --hard paranccsal töröltünk is commiteket, van remény! A Git egy „reflog” (reference log) nevű mechanizmust tart fenn, amely rögzíti a HEAD mutató összes mozgását, beleértve a commitek létrehozását, checkout-okat, reset-eket és merge-eket. Ez egyfajta „biztonsági háló” a lokális repositorynk számára.

Hogyan használjuk a `git reflog`-ot?

Egyszerűen írjuk be a következőt a terminálba:

git reflog

Ez kiírja az összes olyan lépést, amit a HEAD-del tettünk, időrendi sorrendben, és minden bejegyzéshez tartozik egy hash. Keresse meg azt a bejegyzést, ami arra a commitra mutat, amit vissza szeretne állítani. Például:

a1b2c3d HEAD@{0}: commit: Add new feature
e4f5g6h HEAD@{1}: reset: moving to HEAD~2
i1j2k3l HEAD@{2}: commit: Fix typo

Ha például az i1j2k3l commitot szeretnénk visszaállítani egy reset --hard után, használhatjuk a git reset --hard i1j2k3l parancsot. Ezzel a HEAD mutatót visszállítjuk arra a pontra, és az elveszettnek hitt munka visszatér a munkakönyvtárunkba és az előzményekbe.

A git reflog egy rendkívül hasznos eszköz a véletlenül elveszett munka visszaszerzésére, de ne feledjük, hogy csak a helyi repositoryban működik, és csak addig, amíg a Git el nem dönti, hogy a régi, elérhetetlen objektumokat szemétnek nyilvánítja és törli (ez általában több hétig is eltarthat).

Melyik módszert válasszam? A döntés fája

A megfelelő módszer kiválasztása kulcsfontosságú. Íme egy rövid döntési fa:

A commit már megosztásra került (feltöltötted egy távoli repositoryba)?
- IGEN: Használd a git revert parancsot. Ez biztonságos, és nem írja át az előzményeket, így nem zavarja meg a csapat többi tagjának munkáját.
- NEM (még csak a helyi repositorydban van): Folytasd a következő kérdéssel.
Meg akarod tartani a visszavont commitek változásait?
- IGEN:
  - Ha a változásokat azonnal stagingelni akarod (készen az újra commitolásra): Használd a git reset --soft <commit-hash>.
  - Ha a változásokat a munkakönyvtárban akarod tartani, hogy még módosíthasd, mielőtt újra stagingelnéd: Használd a git reset --mixed <commit-hash>.
- NEM (teljesen el akarod felejteni a változásokat): Használd a git reset --hard <commit-hash>. Különösen óvatosan járj el!

Gyakori hibák és legjobb gyakorlatok

Felesleges git reset --hard használata: Soha ne használd ezt a parancsot felelőtlenül! Mindig győződj meg arról, hogy nincs szükséged a változásokra. Ha bizonytalan vagy, használj --soft vagy --mixed módot, vagy egyszerűen készíts egy ideiglenes ágat a munkádról (git branch temp-backup) mielőtt visszavonod.
git push --force használata megosztott ágakon: SOHA ne használj --force parancsot olyan ágon, amin mások is dolgoznak, hacsak nem kommunikáltál előtte a csapattal, és nem vagy biztos a következményekben. Komoly konfliktusokat és adatvesztést okozhat. Használj git push --force-with-lease-t, ha lehetséges, ez egy biztonságosabb opció, amely csak akkor tolja fel a változásokat, ha a távoli ág nem változott meg az utolsó letöltésed óta.
Nem ellenőrzöd a commit hash-t: Mindig alaposan ellenőrizd a commit hash-t, amit használsz, mielőtt bármilyen Git paranccsal módosítanád az előzményeket.
Gyakori commitek: Commítelj gyakran és kis, logikailag összefüggő változtatásokat. Így könnyebb lesz egy-egy hibás commitot visszavonni, anélkül, hogy sok más, jó változást is érintene.
Használj ágakat: Fejlessz külön ágakon, ne közvetlenül a main vagy master ágon. Ez nagyban leegyszerűsíti a hibák javítását és a visszavonásokat, mivel nem befolyásolja közvetlenül a stabil fő ágat.

Összefoglalás

A Git commitok visszavonása alapvető készség minden fejlesztő számára. Két fő eszköz áll rendelkezésünkre: a git revert a biztonságos, előzményeket megtartó visszavonáshoz (megosztott történet esetén), és a git reset az előzmények átírásához (helyi történet esetén). A git reflog pedig a végső mentsvár, ha valami balul sülne el, és egy commitot véletlenül elveszítenénk. Fontos, hogy mindig értsük, melyik parancsot miért és mikor használjuk, különös tekintettel a projekt állapotára (helyi vagy megosztott) és a kívánt eredményre (megtartjuk a változásokat, vagy eldobnánk őket). A Git ereje a rugalmasságában rejlik, de ezzel együtt jár a felelősség is. Gyakorlással és a fent említett legjobb gyakorlatok betartásával magabiztosan kezelhetjük a Git repositoryk előzményeit, és kijavíthatjuk a hibákat, anélkül, hogy a projekt integritását veszélyeztetnénk.