Cum recuperezi commit-urile pierdute cu git reflog?

Question

Accepted Answer

**git reflog** înregistrează unde a fost HEAD-ul branch-ului tău — fiecare commit, checkout, reset, rebase, etc. Este o plasă de siguranță pentru **recuperarea commit-urilor "pierdute"** (după un reset greșit, rebase nereușit sau ștergere de branch) care par dispărute dar sunt încă recuperabile.

## Ce este reflog

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

## Recuperarea lucrărilor pierdute

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

Când commit-urile par pierdute (după `reset --hard`, un rebase nereușit sau ștergerea unui branch), `git reflog` arată unde era HEAD, și poți recupera commit-ul după hash-ul său (verificând-o, creând un branch sau făcând reset la el).

## Scenarii comune de recuperare

```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).
```

## De ce este important

Înțelegerea `git reflog` este valoroasă ca **plasă de siguranță pentru recuperarea lucrărilor pierdute**, deci este o cunoștință practică importantă care te poate salva de la greșeli care par catastrofale.

Operațiile Git care rescriu istoricul sau mută HEAD — `reset --hard`, rebases nereușite, ștergerea de branch-uri — pot face ca commit-urile să **pară pierdute**, ceea ce este alarmanțiu și pare irevocabil.

Intuiția crucială este că aceste commit-uri de obicei **nu sunt de fapt pierdute**: `git reflog` înregistrează fiecare mișcare a HEAD-ului local (fiecare commit, checkout, reset, rebase), inclusiv commit-uri care nu mai sunt accesibile din niciun branch, deci reține unde erau commit-urile "pierdute".

Aceasta face din reflog un puternic **instrument de recuperare** — când lucrarea pare pierdută după un reset greșit, un rebase nereușit sau ștergerea unui branch, poți folosi `git reflog` pentru a găsi hash-ul commit-ului și recupera-l (verificând-o, creând un branch la el sau făcând reset înapoi la el).

Înțelegerea **scenariilor comune de recuperare** (recuperare după `reset --hard`, rebases greșite, ștergerea de branch-uri și commit-uri orfane în detached HEAD) și că recuperarea funcționează atâta timp cât commit-urile existau local (până la garbage collection, de obicei săptămâni mai târziu) este o cunoștință practică valoroasă.

Această plasă de siguranță este liniștitoare și cu adevărat utilă — înseamnă că multe situații "Mi-am pierdut lucrarea!" sunt recuperabile, eliminând o mare parte din frica față de operațiile Git care rescriu istoricul.

Deoarece greșelile care par că pierd commit-urile sunt frecvente (mai ales când înveți sau folosești comenzi puternice ca reset și rebase), și deoarece reflog este instrumentul care le recuperează (transformând adesea o panică într-o reparație rapidă), înțelegerea `git reflog` — ce înregistrează, cum să recuperezi commit-urile pierdute și scenariile comune de recuperare — este o cunoștință Git valoroasă și practic relevantă ca o plasă de siguranță esențială, un instrument care oferă încredere pentru a folosi caracteristicile puternice ale Git știind că lucrarea pierdută poate fi de obicei recuperată, și o cunoștință cu adevărat liniștitoare pentru orice developer.