How do you recover lost commits with git reflog?

Question

Accepted Answer

**git reflog** records where your branch's HEAD has been — every commit, checkout, reset, rebase, etc. It's a safety net for **recovering "lost" commits** (after a bad reset, rebase, or branch deletion) that seem gone but are still recoverable.

## What reflog is

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

## Recovering lost work

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

When commits seem lost (after `reset --hard`, a botched rebase, or deleting a branch), `git reflog` shows where HEAD was, and you can recover the commit by its hash (checking it out, creating a branch, or resetting to it).

## Common recovery scenarios

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

## Why it matters

Understanding `git reflog` is valuable as a **safety net for recovering lost work**, so it's important practical knowledge that can save you from seemingly-catastrophic mistakes.

Git operations that rewrite history or move HEAD — `reset --hard`, botched rebases, deleting branches — can make commits **appear lost**, which is alarming and seems irreversible.

The crucial insight is that these commits usually **aren't actually gone**: `git reflog` records every movement of HEAD locally (every commit, checkout, reset, rebase), including commits no longer reachable from any branch, so it remembers where "lost" commits were.

This makes reflog a powerful **recovery tool** — when work seems lost after a bad reset, a botched rebase, or a deleted branch, you can use `git reflog` to find the commit's hash and recover it (checking it out, creating a branch at it, or resetting back to it).

Understanding the **common recovery scenarios** (recovering after `reset --hard`, bad rebases, branch deletion, and orphaned detached-HEAD commits) and that recovery works as long as the commits existed locally (until garbage collection, typically weeks later) is valuable practical knowledge.

This safety net is reassuring and genuinely useful — it means many "I lost my work!" situations are recoverable, removing much of the fear around Git's history-rewriting operations.

Since mistakes that seem to lose commits are common (especially when learning or using powerful commands like reset and rebase), and since reflog is the tool that recovers them (often turning a panic into a quick fix), understanding `git reflog` — what it records, how to recover lost commits, and the common recovery scenarios — is valuable, practically-relevant Git knowledge as an essential safety net, a tool that provides confidence to use Git's powerful features knowing that lost work can usually be recovered, and a genuinely reassuring piece of knowledge for any developer.