Git Reflog: Recover Lost Commits, Branches & Changes (Rescue Guide for 2026)

Published February 16, 2026 · 16 min read

git reflog is Git’s “undo history”. It records where your branch pointers and HEAD were before resets, rebases, checkouts, and even commit --amend.

If you ever thought “I just lost my commit”, reflog is usually the fastest way to get it back.

1. What is git reflog?

The reflog (reference log) is a local log of updates to refs like HEAD, main, and remote-tracking branches.

Most of the time you’ll use the reflog to recover from commands that move branch pointers:

• git reset (especially --hard)
• git rebase (interactive or otherwise)
• git commit --amend (rewrites the last commit)
• git checkout / git switch (moving HEAD)

View your recent HEAD movements:

git reflog -n 20

Every line corresponds to a previous position. Git gives you a convenient syntax: HEAD@{1} means “where HEAD was one move ago”. You can use it almost anywhere you’d use a commit hash:

# Inspect the previous HEAD
git show HEAD@{1}

# Move your branch back to the previous HEAD
git reset --hard HEAD@{1}

2. Fast recovery recipe (copy/paste)

If you just want your work back, this is the “do this now” sequence:

# 1) Find the old commit
git reflog -n 30

# 2) Inspect candidates (repeat as needed)
git show --stat HEAD@{1}

# 3a) Safest: create a new branch at the old commit
git switch -c recovered-work HEAD@{1}

# 3b) Or: move the current branch back (destructive)
git reset --hard HEAD@{1}

3. Recover after git reset --hard

git reset --hard moves your branch pointer and overwrites files in the working directory. Your commits usually still exist, you just lost the reference to them.

Step 1: find the previous HEAD

git reflog -n 20

Look for the entry right before the reset (often labeled reset:). Then inspect it:

git show --stat HEAD@{1}

Step 2: restore it

# Option A: move your current branch back
git reset --hard HEAD@{1}

# Option B: keep current branch, save the old commit elsewhere
git switch -c pre-reset HEAD@{1}

4. Undo a rebase (or fix a bad rebase)

If your rebase is still running, the easiest fix is usually:

git rebase --abort

If the rebase already completed and you want to go back, use reflog to find the commit from before the rebase and reset back to it.

Find the pre-rebase HEAD

git reflog -n 40

Search for entries like rebase (start), rebase (finish), or your old commit message. Then restore:

git reset --hard HEAD@{n}

5. Recover a deleted branch

Deleting a branch (like git branch -D feature-x) deletes the ref, not the commit objects immediately. If the commits were only referenced by that branch, they become “unreachable” — but usually recoverable.

Option A: you recently checked out that branch

If you were on the branch recently, HEAD reflog often still contains the commit hash you need:

git reflog -n 50

When you find the tip commit, recreate the branch:

git branch feature-x <hash>
git switch feature-x

Option B: search all reflogs

If you’re not sure which ref had it, search all reflogs:

git reflog --all | head

Then recreate the branch at the right commit hash.

6. Recover commits from detached HEAD

A common panic moment is:

1. You checkout a commit directly (git switch --detach <hash> or similar).
2. You make a commit.
3. You switch back to a branch and “lose” the commit.

Reflog records the detached HEAD commit — just find it and create a branch:

git reflog -n 30

# When you find the commit hash:
git switch -c saved-work <hash>

7. Undo git commit --amend (or reword)

git commit --amend replaces the last commit with a new one (new hash). That means the “old” version of the commit is often recoverable in reflog.

# Look for "commit (amend):" entries
git reflog -n 30

# Create a branch at the pre-amend commit
git switch -c pre-amend HEAD@{n}

If your goal is to completely undo the amend and return the branch to the previous commit:

git reset --hard HEAD@{n}

8. Limits: when reflog won’t save you

Reflog is powerful, but it is not magic. Common situations where it doesn’t help:

• Uncommitted work (never committed, never stashed) — Git never had an object to point to.
• A different machine / a different clone — reflog lives in .git/logs in that one repo.
• Aggressive cleanup — commands like git gc --prune=now can permanently drop unreachable objects.

If reflog is gone but you suspect the commit objects still exist, you can try a low-level search for dangling commits:

git fsck --lost-found

9. Best practices to avoid disasters

• Prefer safety on shared branches: use revert for pushed history, not reset.
• Use --force-with-lease if you must force-push: it prevents overwriting teammates’ work.
• Create a backup branch before big rewrites: git branch backup/pre-rebase.
• Commit early, commit often (or stash) before destructive operations.
• Learn the “decision tree”: reset vs revert vs restore vs reflog — see Git Undo.

git branch backup/$(date +%Y%m%d)-before-rebase

FAQ

Does git reflog work if I cloned the repo again?

No — reflog is local to each clone. A fresh clone has a fresh reflog. If you need old history back, you need a clone that still has the commits (often your old clone or a teammate’s).

What if I recovered the commit but my files still look wrong?

Make sure you recovered the right commit. Use git show --stat to inspect candidates. If you want to keep your current state but cherry-pick the recovered commit, you can also cherry-pick it onto your current branch.

Is HEAD@{1} always “before the mistake”?

Not always. It’s simply the previous movement of HEAD. If you ran several commands since the mistake, you may need HEAD@{2}, HEAD@{10}, etc. Inspect with git show until you find the right snapshot.

Want the broader “which undo command should I use?” decision guide? Start with Git Undo: Reset, Revert & Restore.