6. témakör · Eszközök és haladó témák · 28. fejezet
Eltűnt commitok egy reset --hard után, véletlenül törölt ág, egy rejtélyes sor, amiről senki nem tudja, honnan jött, egy javítás, ami rossz ágra került.
Ezekre a helyzetekre való a Git mentőöve. A jó hír: ami egyszer commitolva volt, azt a Git szinte mindig vissza tudja adni — csak tudni kell, hol keresd.
git reflog segítségével visszahozod az „elveszett” commitokat és a törölt ágakat.git blame és a git show segítségével kideríted, ki, mikor és miért írt egy sort.git log --grep, git log -S.git cherry-pick paranccsal egyetlen commitot átemelsz egy másik ágra, és ütközés esetén is boldogulsz.git bisect ötletét a hibát okozó commit megkereséséhez.reset --hard, egy amend, egy rebase vagy egy ágtörlés után isgit stash list)git restore, git reset --hard vagy git checkout -- fájl eldobottgit clean -f-fel törölt, követetlen fájlA Git azt védi, amit commitoltál. Egy „wip” commit egy kockázatos lépés előtt semmibe nem kerül (később összevonhatod, 14. fejezet), egy elveszett délutáni munka viszont sokba.
A reflog (reference log) feljegyzi, hová mutatott a HEAD az elmúlt időszakban: minden commitot, váltást, resetet, merge-et, rebase-t. Akkor is, ha az a commit már egyetlen ágról sem érhető el. (Már a 10. fejezetben is találkoztál vele.)
PS> git reflog a4c19e2 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~2 7e3d0c1 HEAD@{1}: commit: Hírek oldal 52b8f4a HEAD@{2}: commit: Galéria oldal a4c19e2 HEAD@{3}: checkout: moving from kiserlet to main PS> git reset --hard HEAD@{1} # vissza oda, ahol a reset előtt voltunk HEAD is now at 7e3d0c1 Hírek oldal
| Baj | Mentés |
|---|---|
git reset --hard „eltüntetett” commitokat | git reflog → git reset --hard HEAD@{1} (vagy a megtalált hash) |
törölt ág (git branch -D kiserlet) | a törlés kiírja: Deleted branch kiserlet (was 9f2c1b7) → git branch kiserlet 9f2c1b7; ha már nem látod, a reflogban keresd |
| amend előtti változat kellene | git reflog → a commit (amend) előtti sor hash-e |
| elrontott rebase vagy merge | git reset --hard ORIG_HEAD (a művelet előtti HEAD), vagy a reflogból |
A reflog csak a te gépeden létezik, és a bejegyzések idővel lejárnak (alapból 90, illetve az elérhetetlen commitoknál 30 nap). Egy friss klónban üres. A GitHubon törölt PR-ágat a PR oldalán a Restore branch hozza vissza (20. fejezet).
Biztonsági tipp: mielőtt bármi kockázatosat csinálsz (reset, rebase), tegyél egy „könyvjelzőt”: git branch mentes. Az ág megtartja a mostani commitot, bármi történik.
PS> git blame -L 2,3 index.html ^71e3b0a (Kovács Anna 2026-09-15 10:00:00 +0200 2) <p>Foglalkozás: csütörtök 15:00</p> 3c9d4e2f (Szabó Lili 2026-09-19 18:20:00 +0200 3) <p>Kapcsolat: robotka@iskola.hu</p> PS> git show 3c9d4e2f # a teljes commit: üzenet, dátum, minden változás
^ jel: a sor a legelső commit óta változatlan.-L 2,3: csak a 2–3. sor; -L 10,+5: a 10. sortól öt sor.git show <hash> mutatja meg a miértet: a commitüzenetet és a teljes változást. (Ezért fontos a jó commitüzenet, 7. fejezet.)A név vicces, de a cél nem a bűnös megkeresése, hanem a kontextus: miért lett ilyen a sor, milyen feladathoz tartozott, kitől kérdezhetsz. Lehet, hogy a „hibás” sor egy tudatos döntés volt.
| Parancs | Mit talál meg? |
|---|---|
git log --grep="menü" | azokat a commitokat, amelyek üzenetében szerepel a szó |
git log -S "robot2026" | azokat a commitokat, amelyek a kódba behozták vagy kivették a szöveget („csákány”, pickaxe) |
git log -- admin.js | egy fájl összes commitját |
git log --author="Lili" | egy szerző commitjait |
git log --all --oneline | minden ág commitját (nem csak az aktuálisét) |
A cherry-pick („cseresznyeszedés”) egy másik ág egyetlen commitjának változását új commitként teszi az aktuális ágra. Nem olvasztja be az egész ágat, csak azt az egyet.
Előtte: a javítás a kiserlet ágon van
A git switch main és a git cherry-pick 9f2c1b7 után
PS> git switch main PS> git cherry-pick 9f2c1b7 [main 4d8e0a3] fix: e-mail-cím javítása Date: Tue Sep 22 17:05:00 2026 +0200 1 file changed, 1 insertion(+), 1 deletion(-)
-x kapcsoló az üzenetbe írja: (cherry picked from commit …).git cherry-pick A B, vagy egy tartomány: git cherry-pick A..B (A után B-ig).git add → git cherry-pick --continue.
Kiszállás: --abort, az adott commit kihagyása: --skip.| Tipikus helyzet | Megoldás cherry-pickkel |
|---|---|
| A feature ágon javítottál egy hibát, ami a main-en is megvan, de a feature még nincs kész | git switch main, git cherry-pick <javító commit> |
| A main-re commitoltál, pedig a feature ágra kellett volna (még nem push-oltad) | git switch feature, git cherry-pick main; aztán git switch main, git reset --hard HEAD~1 |
| Egy régi kiadást kell javítani (pl. egy v1.x ágon) | a main-en kész javítás átemelése a régi ágra |
Ha egy ág teljes munkája kell, olvaszd be (merge / PR). A sok cherry-pick duplikált commitokat hoz létre (ugyanaz a változás két hash-sel), ami később zavaros történethez és felesleges ütközésekhez vezet.
Melyik eszköz való a helyzethez?
Tegnap még működött, ma nem, és közben 40 commit érkezett. Melyik rontotta el? A bisect bináris kereséssel találja meg: mindig a tartomány felénél kér egy ítéletet (good vagy bad), így 40 commitból kb. 6 lépésben megvan a bűnös.
PS> git bisect start PS> git bisect bad # a mostani állapot hibás PS> git bisect good v1.0.0 # ez a régi kiadás még jó volt Bisecting: 19 revisions left to test after this (roughly 4 steps) # … a Git átvált egy középső commitra: kipróbálod, majd: PS> git bisect good # vagy: git bisect bad # … néhány kör után: 5d7a2c1 is the first bad commit PS> git bisect reset # vissza az eredeti ágra
A szimulátor a bisectet nem futtatja, de ha egyszer egy nagy projektben „valami elromlott valamikor”, emlékezz rá: ez a leggyorsabb út a hibás commithoz.
Mi történt? Válaszd ki, és megkapod a mentés lépéseit.
A robotika klub honlapján (klubhonlap) több baj is van, és te is okozol egyet szándékosan, hogy kipróbáld a mentést. A gráf a reflogban még meglévő,
de ágról már nem elérhető commitokat is mutatja (szaggatott vonallal).
⭐ alap · ⭐⭐ haladó · ⭐⭐⭐ kihívás
Egy gyakorló repóban készíts három commitot, majd git reset --hard HEAD~3. Hozd vissza őket a reflog segítségével. Írd le, melyik sor mutatta a helyes hash-t.
Egy csapatmunka repójában futtasd le a git blame-et egy fájlra, és nézd meg ugyanezt a GitHubon a Blame gombbal. Keress egy sort, és a git show segítségével derítsd ki, miért került oda.
Töröld egy ágadat git branch -D-vel, majd hozd vissza. Próbáld ki úgy is, hogy a törlés kimenetét nem nézed meg, csak a reflogot.
Commitolj szándékosan a main-re, majd tedd át a commitot egy új feature ágra (cherry-pick + reset). Ellenőrizd a git log --oneline --graph --all-lal.
Idézz elő cherry-pick-ütközést (a cél ágon ugyanaz a sor másként változott), oldd fel, és fejezd be a --continue-val. Utána próbáld ki az --abort-ot is.
Keresd meg egy projektben git log -S-sel, melyik commit hozott be egy adott függvénynevet, és --grep-pel a „fix” szót tartalmazó commitokat.
Egy saját gépi repóban (valódi Gittel) próbáld ki a git bisect-et: 10 commitból az egyik szándékosan elront egy számítást. Hány lépésben találja meg a Git?
Az egyválasztós kérdéseknél kattints a válaszra. A többválasztósaknál jelöld be az összes helyeset, majd nyomd meg az Ellenőrzés gombot.
| Fogalom | Jelentés |
|---|---|
| reflog | a HEAD (és az ágak) mozgásainak helyi naplója; innen az ágról már nem elérhető commitok is visszahozhatók |
HEAD@{n} | ahol a HEAD n lépéssel korábban állt |
| ORIG_HEAD | a HEAD helye egy veszélyes művelet (reset, merge, rebase) előtt |
| blame | soronként kiírja, melyik commit, ki és mikor módosította utoljára |
pickaxe (git log -S) | azokat a commitokat keresi, amelyek egy szöveget behoztak vagy kivettek |
| cherry-pick | egy (vagy néhány) commit változásának átemelése új commitként az aktuális ágra |
| bisect | bináris keresés a hibát okozó commitra (good/bad ítéletekkel) |
| árva (elérhetetlen) commit | commit, amelyre már egyetlen ág sem mutat; a reflogból még elérhető, amíg le nem jár |
git branch mentes.git reflog: hol járt a HEAD; mentés: git reset --hard HEAD@{n} vagy git branch név <hash>. Helyi, és lejár.git blame [-L a,b] fájl + git show <hash>: ki, mikor, miért.--grep (üzenetben), -S (kódban), -- fájl, --author.git cherry-pick <hash>: egyetlen commit átemelése (új hash); ütközésnél add → --continue. Egész ághoz inkább merge. Hibakereséshez: git bisect.Ezzel a tananyag új anyagrésze véget ért. A következő, összefoglaló témakör a fogalmak rendszerezésével kezdődik.