Git rarely loses commits; it loses your pointer to them. The reflog is the record of everywhere HEAD has been, and it turns most “I destroyed everything” moments into a two-minute fix.
Find where you were#
git reflog
Every line is a position HEAD held, newest first: checkouts, commits, resets, rebases. Find the entry just before the mistake — its message usually names the operation that went wrong.
Go back there#
git reset --hard HEAD@{2}
Or, safer, put a branch on the good position first and look at it before resetting anything:
git branch rescue HEAD@{2}
The classic recoveries#
git reset --hardone commit too far: the “lost” commit is in the reflog, reset back to it.- Deleted branch you still needed:
git reflog, find the last commit the branch pointed at,git branch the-name <hash>. - Rebase gone wrong: the reflog holds the branch’s pre-rebase position as
HEAD@{n}from before the rebase started.
The limits#
The reflog is local and expires (90 days by default for reachable entries). It saves you from your own commands, not from a disk dying — that is what the remote is for. And uncommitted work that was never staged is genuinely gone; the reflog only tracks commits.
When in doubt, git branch rescue first. A branch you delete after inspecting costs nothing.
Share this post
Keep reading
Git Bisect: Find the Commit That Broke It
The tests passed last week and fail now. Bisect turns 'somewhere in these 40 commits' into six test runs.
What Not to Commit in a Laravel Project
vendor, .env, caches and build output: the short list of what stays out of the repo, and the .gitignore that keeps it out.
What to Do in a Detached HEAD
Detached HEAD sounds like an injury. It is just HEAD pointing at a commit instead of a branch - safe to look around, one command to keep any work.