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.