Recovering with reflog

git reflog is often the most practical recovery tool in everyday Git accidents. After a bad reset, rebase, amend, or pull, what you usually lose first is not the commit object itself but the name and reference that used to point to it.

When reflog is the right first stop

• after a reset --hard you regret
• after a rebase that rewrote history in the wrong way
• after a pull that changed the branch differently than expected
• after deleting a branch and suspecting the commits still exist
• after commit --amend or interactive rebase when you want the previous state back

The real value is that you do not need to know the final recovery plan yet. You only need to relocate the trustworthy old state.

A conservative recovery flow

1. Inspect reflog before trying more mutations

git reflog --date=local

Look for entries that correspond to the operation right before the mistake. Useful clues often include:

• reset: moving to ...
• rebase (start) / rebase (finish)
• checkout: moving from ... to ...
• commit (amend): ...

2. Create a rescue branch before resetting anything

git switch -c rescue/recover HEAD@{1}

If HEAD@{1} is not the correct entry, use the SHA or another reflog position instead.
The goal here is not to finish the recovery immediately. It is to pin the old state somewhere safe so later experiments do not erase your best recovery target.

3. Choose the real restoration path afterward

• want the current branch to return to that state: git reset --hard <target>
• want to keep today’s state and recover in parallel: continue on the rescue/* branch
• want only some commits back: git cherry-pick <sha>
• want to compare both sides first: git log --oneline --graph --decorate --all

Why “branch first, reset later” is safer

Many people know reflog is useful, but still jump straight from “I found the old SHA” to “I will reset immediately.” The problem is that recovery commands are also reference-moving commands. If you guess wrong once, you can make the situation harder to reason about.

A safer rhythm is:

1. run git reflog
2. create rescue/...
3. inspect content and history on that rescue branch
4. only then decide whether the original branch should move

This costs a little more time, but incident response is usually better when it is calm and reversible.

Three common recovery situations

Recover after reset

Your job is to find the branch tip from before the reset, pin it on a rescue branch, and only then decide whether the original branch should be moved back.

Recover after rebase

Do not focus first on which SHAs changed. Focus on where the branch pointed before the rebase started. Reflog usually makes that visible quickly.

Recover after pull

First understand what the pull actually did:

• fast-forward
• merge
• or rebase

Then use reflog to locate the pre-pull position. Do not hard-reset blindly before you know what changed.

Reflog is powerful, but it has limits

• reflog is local, not a shared cross-machine audit log
• entries are not kept forever
• aggressive cleanup and time can shrink the recovery window
• success still depends on whether the old objects remain available

That is why the best habit is to create a rescue branch as soon as you find a meaningful old position.

Common mistakes

Resetting immediately after finding an old SHA

You may be right, but it is still the riskier sequence. Branch first if you want a reversible path.

Thinking reflog matters only after reset

Checkout, merge, rebase, amend, and pull can all leave useful reflog entries.

Assuming deleted branch means deleted commits

Sometimes only the name disappeared. The objects may still exist and be recoverable.

mkdir reflog-lab && cd reflog-lab
git init
echo one > notes.txt
git add notes.txt
git commit -m "init"
echo two >> notes.txt
git commit -am "second"
echo three >> notes.txt
git commit -am "third"

The habit worth remembering

When Git history looks wrong, start with this:

1. git reflog
2. create a rescue branch
3. choose reset, cherry-pick, merge, or manual reconstruction only after the old position is safe