Hvordan gjenoppretter du tapte commits med git reflog?

Question

Accepted Answer

**git reflog** registrerer hvor din branches HEAD har vært — hver commit, checkout, reset, rebase, osv. Det er et sikkerhetsnett for **gjenoppretting av "tapte" commits** (etter en dårlig reset, rebase eller branch-sletting) som ser ut til å være forsvunnet men fortsatt kan gjenopprettes.

## Hva 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.
```

## Gjenopprette tapt arbeid

```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 ser ut til å være tapte (etter `reset --hard`, en mislykket rebase eller sletting av en branch), viser `git reflog` hvor HEAD var, og du kan gjenopprette commiten ved hjelp av dens hash (ved å sjekke den ut, opprette en branch eller resette til den).

## Vanlige gjenopprettingsscenarioer

```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 er viktig

Å forstå `git reflog` er verdifullt som et **sikkerhetsnett for gjenoppretting av tapt arbeid**, så det er viktig praktisk kunnskap som kan spare deg fra tilsynelatende katastrofale feil.

Git-operasjoner som omskriver historikk eller flytter HEAD — `reset --hard`, mislykket rebasing, sletting av branches — kan få commits til å **virke tapte**, noe som er alarmerende og virker irreversibelt.

Den avgjørende innsikten er at disse commitene vanligvis **ikke faktisk er borte**: `git reflog` registrerer hver bevegelse av HEAD lokalt (hver commit, checkout, reset, rebase), inkludert commits som ikke lenger er nåbare fra noen branch, så den husker hvor "tapte" commits var.

Dette gjør reflog til et kraftfullt **gjenopprettingsverktøy** — når arbeid ser ut til å være tapt etter en dårlig reset, en mislykket rebase eller en slettet branch, kan du bruke `git reflog` til å finne commitens hash og gjenopprette den (ved å sjekke den ut, opprette en branch på den eller resette tilbake til den).

Å forstå **vanlige gjenopprettingsscenarioer** (gjenoppretting etter `reset --hard`, dårlige rebases, branch-sletting og foreldreløse detached-HEAD commits) og at gjenoppretting fungerer så lenge commitene eksisterte lokalt (til garbage collection, typisk uker senere) er verdifull praktisk kunnskap.

Dette sikkerhetsnett er beroligende og genuint nyttig — det betyr at mange "Jeg tapte arbeidet mitt!" situasjoner er gjennoprettbare, noe som fjerner mye av frykten rundt Gits historikkomskriving.

Ettersom feil som virker å tape commits er vanlige (spesielt når man lærer eller bruker kraftfulle kommandoer som reset og rebase), og siden reflog er verktøyet som gjenoppretter dem (ofte gjør en panikk til en rask løsning), er forståelse av `git reflog` — hva det registrerer, hvordan du gjenoppretter tapte commits, og de vanlige gjenopprettingsscenarioene — verdifull, praktisk relevant Git-kunnskap som et essensielt sikkerhetsnett, et verktøy som gir tillit til å bruke Gits kraftfulle funksjoner med viten om at tapt arbeid vanligvis kan gjenopprettes, og en genuint beroligende kunnskapsbit for enhver utvikler.