git reflog

git reflog records where refs such as HEAD have pointed over time. That makes it central to recovery workflows.

Why it matters

After operations like:

• reset --hard
• rebase
• pull
• branch deletion or history rewrite

the old commits may still exist, but the visible branch name may no longer point at them. Reflog helps you find those older positions.

Common examples

git reflog
git reflog show HEAD
git reset --hard HEAD@{1}
git checkout -b rescue HEAD@{2}

Best workflow

1. inspect reflog
2. locate the pre-mistake position
3. either create a rescue branch or move the ref back

Key distinction

• git log shows commit history
• git reflog shows reference movement history

That difference is why reflog is so useful when normal history still exists but your pointer is no longer where you expected.

What problem this command solves in a workflow

git reflog is a read-only diagnostic tool that records the history of where references (especially HEAD and branch refs) have pointed. It does not modify commits, move refs, or reshape history — it simply reads and displays the ref movement log. Every checkout, reset, rebase, merge, and pull leaves a trail entry that reflog can surface, making it the primary recovery tool when you've lost track of a commit.

Typical use cases

• Recovering from an accidental reset --hard — reflog shows you exactly where HEAD pointed before the reset.
• Finding lost commits after a rebase or branch deletion — the old commits still exist in the object store; reflog reveals their hashes.
• Understanding what operations have been performed on a branch — reflog provides a chronological audit trail of ref changes.
• Creating a rescue branch at a specific historical position before attempting further corrective action.

Diagram view

Special cases and boundaries

• Reflog entries expire over time (default: 90 days for reachable entries, 30 days for unreachable). Do not treat reflog as a permanent archive — act quickly if you need recovery.
• Reflog is local to each repository. It is not shared via push/fetch, so you cannot recover ref movements that happened on another machine.
• git reflog show <ref> shows the reflog for a specific ref (e.g., refs/heads/main). Without arguments, it defaults to HEAD.
• Reflog entries use syntax like HEAD@{1} (one step ago) or HEAD@{2023-01-15} (position on a specific date).
• Reflog only tracks ref movements, not arbitrary object creation. If a commit was never pointed to by a ref, it will not appear in reflog.

Try it yourself

git switch -c lab/reflog-demo
# make two commits
# then run git reset --hard HEAD~1