Een doorloop van de tutorial Verloren commits terughalen: hoe git reset --hard lijkt op het verwijderen van een commit, en hoe git reflog hem weer terugvindt zodat je hem kunt herstellen.
Dit scenario leert het meest geruststellende feit van Git: een commit die je met git reset --hard "kwijt bent geraakt", is er meestal nog. Je ziet de commit uit de geschiedenis verdwijnen en haalt hem dan terug met git reflog.
De situatie
Git koppelt elke commit aan zijn ouder en bewaart hem op hash, dus niets wordt echt verwijderd.
Het project heeft drie commits: Initial commit, Add header navigation en Add skills section. Na een git reset --hard die net één stap te ver ging, verschijnt de laatste commit niet meer in git log. Hij lijkt verwijderd.
Dat is hij niet. De reset zette de branchwijzer terug en liet de commit Add skills section op zijn plek staan, maar zonder referentie. Git herinnert zich hem nog.
git reset --hard gooit werkwijzigingen weg en verplaatst de branch, vandaar het destructieve gevoel. Het commit-object overleeft, maar de enige eenvoudige weg terug loopt via het reflog.
Het herstel, stap voor stap
Zodra git reflog je de hash geeft, wijs je een branch er weer naartoe om de commit te herstellen.
Zien dat de commit weg is
git log
Het log eindigt nu bij Add header navigation. De skills-commit is uit dit overzicht verdwenen, en dat is het symptoom waarvan je herstelt.
Hem in het reflog vinden
git reflog
Het reflog noemt elke beweging van HEAD, inclusief de Add skills section-commit van vóór de reset. Noteer de hash (of de HEAD@{n}-referentie).
De branch op die commit zetten
git reset --hard <commit-hash>
De branch op de hash van de verloren commit zetten brengt Add skills section terug in git log. De geschiedenis is weer compleet.
Waarom de commit te redden was
Een commit blijft bestaan zolang iets ernaar verwijst, en daarom kan het reflog hem terugbrengen.
git log en git reflog beantwoorden verschillende vragen:
git log toont commits die bereikbaar zijn vanaf de huidige branch. Een reset haalt de commit uit die keten, dus hij verdwijnt hier.
git reflog toont waar HEAD is geweest, met of zonder branch. De verloren commit staat er nog, met de hash die je nodig hebt om terug te gaan.
Je kunt zowel de ruwe hash als de referentie in HEAD@{1}-stijl uit het reflog kopiëren. Beide werken met git reset --hard.
Het reflog is lokaal aan je kloon. Het is een persoonlijk vangnet, niet gedeeld met de remote, en daarom altijd beschikbaar voor je eigen fouten.
Verschillende soorten verloren werk terughalen
git reflog is de eerste plek om te kijken bij bijna elk "ik ben het kwijt"-moment, omdat het elke positie vastlegt die HEAD heeft ingenomen:
- Na
git reset --hard — zoek de commit in git reflog, gevolgd door git reset --hard <hash> om er weer naartoe te gaan (of git checkout <hash> om eerst te kijken).
- Een verwijderde branch — de tip staat nog in het reflog; maak hem opnieuw aan met
git branch <name> <hash>.
- Een mislukte rebase of amend — de commits van voor de rebase staan in het reflog; reset terug naar de entry van voordat hij liep.
- Wanneer het reflog hem niet meer heeft — entries verlopen (standaard na ongeveer 90 dagen, of na
git gc). git fsck --lost-found kan soms nog losse commits naar boven halen.
Probeer het hier: maak een commit, reset --hard hem weg, en haal hem daarna terug uit het reflog. Zodra je het één keer hebt gedaan, is reset --hard niet eng meer.