Återställa förlorade commits och brancher

I Git innebär förlorat arbete ofta att det bara är tillfälligt oåtkomligt, inte permanent borttaget. Gits interna mekanismer bevarar en detaljerad historik, vilket gör återställning möjlig.

I den här lektionen får du lära dig avancerade tekniker för att återställa commits och brancher och även lösa besvärliga situationer som ett detached HEAD.

Du känner kanske redan till att git reflog är ett kraftfullt verktyg. Det registrerar nästan varje ändring av din HEAD och skapar i praktiken en lokal historik över repots tillstånd.

Tänk på det som en loggbok över var din HEAD-pekare har befunnit sig, även efter reset, merge och checkout. Det är ditt första verktyg vid återställning.

Varje post i din reflog har ett specifikt format. Att förstå det är nyckeln till att hitta det du behöver:

• HEAD@{n}: Anger HEAD:s tillstånd för 'n' steg sedan.
• Commit-hashen: Den faktiska SHA-1-identifieraren för committen.
• Åtgärden: En beskrivning av vad som hände (t.ex. commit, reset eller checkout).

Genom att gå igenom dessa poster kan du hitta exakt den commit du vill återställa.

Ett vanligt scenario är att du råkar använda git reset --hard och förlorar ditt senaste arbete. Få inte panik! Din commit finns fortfarande i reflog.

Du kan hitta hashen för den ”förlorade” committen i reflog och sedan använda git reset --hard för att flytta den aktuella branchens HEAD tillbaka till den specifika committen.

Vi simulerar att en commit förloras och återställer den sedan. Vi skapar en commit, ”förlorar” den med en hard reset och använder därefter reflog för att få tillbaka den.

Kör dessa kommandon i din terminal:

Råkade du ta bort en branch med git branch -D my-feature? Git förstör inte committerna direkt, utan tar bara bort pekaren.

Använd git reflog för att hitta den senaste commit som den borttagna branchen pekade på. När du har commit-hashen kan du helt enkelt återskapa branchen från den punkten.

Ett ”detached HEAD” uppstår när din HEAD pekar direkt på en commit i stället för på en namngiven branch. Commits som skapas i detta tillstånd tillhör ingen branch om du inte uttryckligen skapar en.

Åtgärda det genom att skapa en ny branch vid den aktuella positionen för HEAD med git branch <new-branch-name> och sedan byta till den med git checkout <new-branch-name>.

För ännu djupare återställning eller integritetskontroller är git fsck (kontroll av filsystemet) rätt verktyg. Det verifierar integriteten i ert Git-repositorium och kan hitta ”hängande” objekt som inte refereras av någon ref (gren, tagg eller reflog-post).

Med git fsck --lost-found kan dessa orefererade objekt (commits, blobs) flyttas till katalogen .git/lost-found/, så att ni får möjlighet att granska och eventuellt återställa dem manuellt.

Även om Git erbjuder robusta återställningsmöjligheter är det alltid bättre att förebygga dataförlust:

• Commit ofta: Små, frekventa commits innebär mindre att förlora.
• Push ofta: Fjärrrepositorier fungerar som säkerhetskopior.
• Beskrivande meddelanden: Gör det enklare att identifiera commits i reflog.
• Säkerhetskopiera .git: För kritiska projekt kan ni överväga att säkerhetskopiera själva katalogen .git.

Grattis! Ni behärskar nu avancerade tekniker för återställning i Git. Ni kan nu:

• Identifiera och återställa ”förlorade” commits med git reflog.
• Återuppliva grenar som råkat tas bort.
• Navigera i och åtgärda ett tillstånd med ”detached HEAD”.
• Använda git fsck för djupare granskning och återställning av repositoriet.

Kom ihåg att regelbundet pusha ert arbete till fjärrrepositorier som ert främsta skydd mot dataförlust!