Hvordan gendanner du tabte commits med git reflog?

Question

Accepted Answer

**git reflog** registrerer hvor dit branches HEAD har været — hver commit, checkout, reset, rebase osv. Det er et sikkerhedsnet til **gendannelse af "tabte" commits** (efter et dårligt reset, rebase eller branch-sletning), der virker væk, men stadig kan gendannes.

## Hvad reflog er

```text
The REFLOG logs every movement of HEAD (and branch tips) in YOUR local repo:
  → every commit, checkout, reset, rebase, merge, etc. is recorded with a reference
  → it's LOCAL and includes commits not reachable from any branch (the "lost" ones)
→ Even if you reset/rebase away commits, reflog remembers where they were.
```

## Gendannelse af tabt arbejde

```bash
git reflog                     # show the history of HEAD movements
# example output:
#   abc123 HEAD@{0}: reset: moving to HEAD~3
#   def456 HEAD@{1}: commit: Important work    ← the "lost" commit!
#   ...

# recover: the lost commit is def456 — get it back
git checkout def456            # inspect it
git branch recovered def456    # create a branch at it (save it)
# or reset back to it:
git reset --hard def456        # restore HEAD to that commit
```

Når commits virker tabte (efter `reset --hard`, et mislykkedes rebase eller sletning af en branch), viser `git reflog` hvor HEAD var, og du kan gendanne commiten ved hjælp af dens hash (ved at tjekke den ud, oprette en branch eller nulstille til den).

## Almindelige gendannelsesscenarier

```text
✓ After git reset --hard (discarded commits) → find them in reflog, reset back
✓ After a bad rebase (rewrote/lost commits) → reflog has the pre-rebase state
✓ After deleting a branch → its last commit is in reflog → recreate the branch
✓ "Detached HEAD" commits that seem orphaned → reflog finds them
→ As long as commits existed locally, reflog usually can recover them (until GC, ~weeks).
```

## Hvorfor det betyder noget

Forståelse af `git reflog` er værdifuld som et **sikkerhedsnet til gendannelse af tabt arbejde**, så det er vigtig praktisk viden, der kan redde dig fra tilsyneladende katastrofale fejl.

Git-operationer, der omskriver historik eller flytter HEAD — `reset --hard`, mislykkedes rebaser, sletning af branches — kan få commits til at virke **væk**, hvilket er alarmerende og virker irreversibelt.

Den vigtige indsigt er, at disse commits sædvanligvis **ikke er rent faktisk væk**: `git reflog` registrerer hver bevægelse af HEAD lokalt (hver commit, checkout, reset, rebase), herunder commits, der ikke længere kan nås fra nogen branch, så det husker hvor "tabte" commits var.

Dette gør reflog til et kraftfuldt **gendannelsesværktøj** — når arbejde virker tabt efter et dårligt reset, et mislykkedes rebase eller en slettet branch, kan du bruge `git reflog` til at finde committes hash og gendanne den (ved at tjekke den ud, oprette en branch på den eller nulstille tilbage til den).

Forståelse af de **almindelige gendannelsesscenarier** (gendannelse efter `reset --hard`, dårlige rebaser, branch-sletning og forældreløse detached-HEAD commits) og at gendannelse fungerer så længe commitsene eksisterede lokalt (indtil garbage collection, typisk uger senere) er værdifuld praktisk viden.

Dette sikkerhedsnet er beroligende og genuin nyttigt — det betyder, at mange "Jeg mistede mit arbejde!" situationer er gendanningsbare, hvilket fjerner meget af frygten omkring Gits historieresskrivningsoperationer.

Da fejl, der virker at miste commits, er almindelige (især når man lærer eller bruger kraftfulde kommandoer som reset og rebase), og da reflog er værktøjet, der gendanner dem (ofte ved at omdanne en panik til en hurtig rettelse), er forståelsen af `git reflog` — hvad det registrerer, hvordan man gendanner tabte commits, og de almindelige gendannelsesscenarier — værdifuld, praktisk relevant Git-viden som et væsentligt sikkerhedsnet, et værktøj, der giver tillid til at bruge Gits kraftfulde funktioner vidende at tabt arbejde normalt kan gendannes, og et genuin beroligende stykke viden for enhver udvikler.