Как восстановить потерянные коммиты с помощью git reflog?

Question

Accepted Answer

**git reflog** записывает, где находился HEAD вашей ветки — каждый коммит, переключение, reset, rebase и так далее. Это подстраховка для **восстановления «потерянных» коммитов** (после неудачного reset, rebase или удаления ветки), которые кажутся исчезнувшими, но всё ещё подлежат восстановлению.

## Что такое 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.
```

## Восстановление потерянной работы

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

Когда коммиты кажутся потеряными (после `reset --hard`, неудачного rebase или удаления ветки), `git reflog` показывает, где был HEAD, и вы можете восстановить коммит по его хешу (проверив его, создав ветку или выполнив reset на него).

## Частые сценарии восстановления

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

## Почему это важно

Понимание `git reflog` ценно как **подстраховка для восстановления потерянной работы**, поэтому это важные практические знания, которые могут спасить вас от кажущихся катастрофическими ошибками.

Операции Git, которые переписывают историю или перемещают HEAD — `reset --hard`, неудачные rebases, удаление веток — могут заставить коммиты **казаться потерянными**, что вызывает беспокойство и кажется необратимым.

Ключевая идея в том, что эти коммиты обычно **фактически не исчезают**: `git reflog` записывает каждое движение HEAD локально (каждый коммит, переключение, reset, rebase), включая коммиты, больше не достижимые ни из одной ветки, поэтому помнит, где находились «потерянные» коммиты.

Это делает reflog мощным **инструментом восстановления** — когда работа кажется потерянной после неудачного reset, неудачного rebase или удалённой ветки, вы можете использовать `git reflog` для поиска хеша коммита и его восстановления (проверив его, создав ветку или выполнив reset).

Понимание **частых сценариев восстановления** (восстановление после `reset --hard`, плохих rebases, удаления веток и сиротских коммитов в detached HEAD) и того, что восстановление работает до тех пор, пока коммиты существовали локально (до сборки мусора, обычно через несколько недель), — ценные практические знания.

Эта подстраховка обнадёживает и действительно полезна — это означает, что многие ситуации «Я потерял свою работу!» подлежат восстановлению, убирая большой страх перед операциями Git, переписывающими историю.

Поскольку ошибки, которые кажутся теряющими коммиты, часты (особенно при обучении или использовании мощных команд, таких как reset и rebase), а reflog — это инструмент, который их восстанавливает (часто превращая панику в быстрое исправление), понимание `git reflog` — что он записывает, как восстанавливать потерянные коммиты и частые сценарии восстановления — это ценные, практически релевантные знания Git как существенная подстраховка, инструмент, который даёт уверенность использовать мощные возможности Git, зная, что потерянную работу обычно можно восстановить, и действительно обнадёживающая информация для любого разработчика.