Jak odzyskać utracone commity za pomocą git reflog?

Question

Accepted Answer

**git reflog** rejestruje, gdzie znajdowała się HEAD Twojej gałęzi — każdy commit, checkout, reset, rebase itp. To sieć bezpieczeństwa do **odzyskiwania "utraconych" commitów** (po złym resecie, rebasing'u lub usunięciu gałęzi), które wydają się zniknięte, ale są nadal możliwe do odzyskania.

## Co to jest 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.
```

## Odzyskiwanie utraconej pracy

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

Gdy commity wydają się utracone (po `reset --hard`, nieudanym rebasie lub usunięciu gałęzi), `git reflog` pokazuje, gdzie była HEAD, i możesz odzyskać commit po jego hash'u (go czekując, tworząc gałąź lub resetując do niego).

## Typowe scenariusze odzyskiwania

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

## Dlaczego to ważne

Rozumienie `git reflog` jest cenne jako **sieć bezpieczeństwa do odzyskiwania utraconej pracy**, więc to ważna praktyczna wiedza, która może Cię uratować przed pozornie katastrofalnymi błędami.

Operacje Git, które przepisują historię lub przesuwają HEAD — `reset --hard`, nieudane rebase'y, usuwanie gałęzi — mogą sprawić, że commity **wydają się utracone**, co jest alarmujące i wydaje się nieodwracalne.

Kluczowym spostrzeżeniem jest to, że te commity zwykle **nie są naprawdę zniknięte**: `git reflog` rejestruje każdy ruch HEAD lokalnie (każdy commit, checkout, reset, rebase), włącznie z commitami, które nie są już dostępne z żadnej gałęzi, więc pamięta, gdzie były "utracone" commity.

To czyni reflog potężnym **narzędziem do odzyskiwania** — gdy praca wydaje się utracona po złym resecie, nieudanym rebasie lub usuniętej gałęzi, możesz użyć `git reflog` do znalezienia hash'u commita i jego odzyskania (go czekując, tworząc w nim gałąź lub resetując do niego).

Rozumienie **typowych scenariuszy odzyskiwania** (odzyskiwanie po `reset --hard`, złych rebase'ach, usunięciu gałęzi i osieroconych commitach detached-HEAD) oraz że odzyskanie działa dopóki commity istniały lokalnie (aż do garbage collection, zwykle kilka tygodni później) jest cenna praktyczną wiedzą.

Ta sieć bezpieczeństwa jest uspokajająca i naprawdę użyteczna — oznacza, że wiele sytuacji "Utraciłem moją pracę!" jest możliwych do odzyskania, usuwając wiele strachu wokół operacji Git'a, które przepisują historię.

Ponieważ błędy, które wydają się tracić commity, są powszechne (szczególnie podczas nauki lub używania potężnych poleceń takich jak reset i rebase), a ponieważ reflog jest narzędziem, które je odzyskuje (często zamieniając panikę w szybką poprawkę), rozumienie `git reflog` — co rejestruje, jak odzyskać utracone commity i typowe scenariusze odzyskiwania — jest wartościową, praktycznie istotną wiedzą Git'a jako niezbędną sieć bezpieczeństwa, narzędzie, które daje pewność do używania potężnych funkcji Git'a wiedząc, że utracona praca zwykle może być odzyskana, i naprawdę uspokajającą wiedzą dla każdego deweloperów.