Git Reflog After the Wrong Reset

Photo: Unsplash.

After a mistaken git reset --hard, the branch may no longer point to the commit you wanted, but the commit often still exists. Before running more recovery commands, inspect the local reference log:

git reflog --date=iso

A short example might look like this:

7c08c1a HEAD@{2024-09-27 21:14:06 +0800}: reset: moving to HEAD~2
4a6f93d HEAD@{2024-09-27 21:12:41 +0800}: commit: finish parser tests

The second line records where HEAD pointed before the reset. Inspect that object before changing anything:

git show --stat 4a6f93d
git show 4a6f93d

If it is the missing commit, create a rescue branch first:

git branch rescue/parser-tests 4a6f93d

This gives the commit a normal reachable reference while you decide whether to merge, cherry-pick, or reset the original branch. Creating a rescue branch is less stressful than immediately moving the current branch again.

For example, to apply only that commit onto the current branch:

git cherry-pick 4a6f93d

Or, after verifying the working tree and intended branch, move the branch back:

git reset --hard 4a6f93d

The last command is destructive to uncommitted tracked changes, so it belongs after inspection, not at the beginning of recovery.

What reflog can and cannot do

Reflogs are local. A colleague’s clone does not contain your branch movements, and a newly cloned repository cannot recover commits that existed only in your old clone. Reflog entries can also expire and unreachable objects may eventually be pruned.

If uncommitted changes were overwritten by reset --hard, reflog usually cannot reconstruct them because they were never stored as commits or other Git objects. An editor’s local history or filesystem backup may still help.

The calm sequence is: stop, read the reflog, inspect the candidate commit, create a rescue reference, then choose the final recovery operation.

Reference

• Git documentation: git-reflog