Verloren commits en branches herstellen

In Git betekent werk verliezen vaak dat het tijdelijk buiten direct bereik is, niet dat het permanent is verwijderd. De interne mechanismen van Git bewaren een gedetailleerde geschiedenis, waardoor herstel mogelijk is.

In deze les leer je geavanceerde technieken om commits en branches te herstellen en lastige situaties zoals een detached HEAD op te lossen.

Je weet misschien al dat git reflog een krachtig hulpmiddel is. Het registreert vrijwel elke wijziging aan je HEAD en maakt zo effectief een lokale geschiedenis van de toestand van je repository.

Zie het als een logboek van de plekken waar je HEAD-pointer is geweest, ook na resets, merges en checkouts. Dit is je eerste halte bij herstel.

Elke vermelding in je reflog heeft een specifieke indeling. Als je die begrijpt, kun je vinden wat je nodig hebt:

• HEAD@{n}: geeft de toestand van HEAD n stappen geleden aan.
• De commit-hash: de werkelijke SHA-1-identificatie van de commit.
• De actie: een beschrijving van wat er is gebeurd (bijvoorbeeld commit, reset of checkout).

Door deze vermeldingen te scannen, kun je precies de commit vinden die je wilt herstellen.

Een veelvoorkomend scenario: je gebruikt per ongeluk git reset --hard en verliest je laatste werk. Geen paniek! Je commit staat nog in de reflog.

Je kunt de commit-hash van je 'verloren' commit in de reflog vinden en vervolgens git reset --hard gebruiken om de HEAD van je huidige branch terug naar die specifieke commit te verplaatsen.

Laten we simuleren dat we een commit verliezen en deze daarna herstellen. We maken een commit, 'verliezen' deze met een hard reset en gebruiken vervolgens reflog om deze terug te krijgen.

Voer deze opdrachten uit in je terminal:

Per ongeluk een branch verwijderd met git branch -D my-feature? Git vernietigt de commits niet meteen; het verwijdert alleen de pointer.

Gebruik git reflog om de laatste commit te vinden waarnaar je verwijderde branch wees. Zodra je de commit-hash hebt, kun je de branch eenvoudig vanaf dat punt opnieuw maken.

Een 'detached HEAD' ontstaat wanneer je HEAD rechtstreeks naar een commit wijst en niet naar een benoemde branch. Commits die in deze toestand worden gemaakt, maken geen deel uit van een branch, tenzij je er expliciet een maakt.

Om dit op te lossen, maak je eenvoudig een nieuwe branch op de huidige positie van je HEAD met git branch <new-branch-name> en schakel je er vervolgens naartoe met git checkout <new-branch-name>.

Voor nog grondiger herstel of integriteitscontroles is git fsck (controle van het bestandssysteem) je hulpmiddel. Hiermee controleer je de integriteit van je Git-opslagplaats en kun je zwevende objecten vinden waarnaar geen enkele ref verwijst (branch, tag of reflog-vermelding).

Met git fsck --lost-found kun je deze objecten waarnaar niet wordt verwezen (commits, blobs) verplaatsen naar de map .git/lost-found/. Zo krijg je de kans om ze te inspecteren en mogelijk handmatig te herstellen.

Hoewel Git krachtige herstelmogelijkheden biedt, is gegevensverlies voorkomen altijd beter:

• Commit vaak: Kleine, regelmatige commits betekenen dat je minder kunt kwijtraken.
• Push regelmatig: Externe opslagplaatsen fungeren als back-ups.
• Beschrijvende berichten: Hiermee kun je commits in de reflog herkennen.
• Maak een back-up van .git: Overweeg voor kritieke projecten een back-up te maken van de map .git zelf.

Gefeliciteerd! Je beheerst nu geavanceerde hersteltechnieken in Git. Je kunt nu:

• ‘Verloren’ commits identificeren en herstellen met git reflog.
• Per ongeluk verwijderde branches opnieuw tot leven brengen.
• Navigeren in en herstellen van een ‘detached HEAD’-status.
• git fsck gebruiken voor grondigere inspectie en herstel van de opslagplaats.

Vergeet niet om je werk regelmatig naar externe opslagplaatsen te pushen. Dat is je belangrijkste bescherming tegen gegevensverlies!