Every git user eventually has that moment. The terminal returns. The working directory looks wrong. You type git log and the last two hours of work are simply not there.
Usually, this is not data loss. It is a solvable problem, and git reflog is what solves it.
What reflog actually is
git reflog records every position HEAD has pointed to on your machine. Every commit, checkout, merge, rebase, and reset leaves an entry. Those entries stick around for about 90 days (30 for unreachable commits). Unless you went out of your way to purge them, your work is still in the object store.
git reflog
Output looks like this:
a1b2c3d (HEAD -> main) HEAD@{0}: commit: fix login
7d8e9f0 HEAD@{1}: reset: moving to HEAD~3
c4d5e6f HEAD@{2}: commit: refactor auth
b1c2d3e HEAD@{3}: commit: add tests
e7f8a9b HEAD@{4}: commit: wire up API
Read it top-down as "what I did recently." HEAD@{1} was the reset that caused the problem. HEAD@{2} is the commit that existed right before the reset — and it is still in there.
Scenario 1 — You ran git reset --hard and want it back
You meant to reset one commit, reset three, and now git log shows nothing recent.
git reflog
Find the entry immediately before the reset. In the example above, that is HEAD@{2}. Restore it:
git reset --hard HEAD@{2}
Done. Working tree, commits, everything — exactly where you were.
One thing worth noting: reflog covers committed history, not unstaged edits. If you had uncommitted changes in the working tree when you reset, those are gone. The habit of committing early (even a git commit -m "wip" before a destructive operation) pays off here.
Scenario 2 — You deleted a branch with unmerged work
git branch -D feature/old-thing
The shell returned, and then you realized. The branch pointer is gone. git branch no longer shows it.
The commits themselves are still in the object store. Reflog still has them:
git reflog show --all | grep -i "feature/old-thing"
Once you spot the commit hash (the tip of the lost branch works best), recreate the branch:
git branch feature/old-thing a1b2c3d
git checkout feature/old-thing
Right back where you were.
Scenario 3 — A rebase went sideways and you already finished it
git rebase --abort during an in-progress rebase is the clean exit. But if you only noticed the damage after the rebase completed:
git reflog
You will see rebase -i (start) and rebase -i (finish). The commit immediately before (start) is your pre-rebase state:
a1b2c3d HEAD@{0}: rebase -i (finish): returning to refs/heads/feature
7d8e9f0 HEAD@{1}: rebase -i (start): checkout ...
c4d5e6f HEAD@{2}: commit: the work you want back
Restore:
git reset --hard HEAD@{2}
The rebase never happened.
Scenario 4 — You committed to the wrong branch and then wiped it
You committed a hotfix directly to main, reset main back, and maybe even force-pushed. Now the commit is nowhere in git log.
If the force-push happened before anyone else pulled, or if you are looking at your local machine, the commit is still findable:
git reflog | grep -i "hotfix"
Found it:
git checkout -b hotfix/correct-branch a1b2c3d
New branch, right commit. Push normally from there.
Nuclear option: git fsck
When you are not sure what happened and reflog is not showing what you expect, git fsck finds dangling commits — commits that exist in the object store but no branch or tag points to:
git fsck --lost-found
Output includes lines like dangling commit a1b2c3d.... Inspect each with git show a1b2c3d until you find the work, then pin a branch to it:
git branch rescue a1b2c3d
Make reflog last longer
Default expiration is 90 days for reachable entries and 30 for unreachable. If you want a longer safety window:
git config --global gc.reflogExpire 180.days
git config --global gc.reflogExpireUnreachable 90.days
The reflog is plain text. Doubling its retention period costs almost nothing.
The habit that saves you
git reflog is the first thing to run any time you feel that "wait, what just happened" jolt. Most recoveries are in the top five lines of output. It takes ten seconds, and once you've used it to pull work back from apparent oblivion, you stop dreading destructive operations quite as much.
This tutorial also appears on SysEmperor, alongside free tools for sysadmins and developers.
Top comments (0)