How to Recover a Deleted Git Commit or Branch with Reflog

A deleted local branch or an accidental git reset --hard does not always mean the commit is gone. Git normally records recent movements of local references in the reflog. The safest recovery is to locate the correct commit, inspect it, and create a new rescue branch before changing the branch you are currently using.

Identify what was lost

Confirm the repository and working state

Open a terminal inside the affected repository and run:

git status
git rev-parse --show-toplevel

Confirm that the displayed repository is the one where the branch or commit existed. If the working tree currently contains valuable uncommitted changes, copy the repository folder or create a separate backup before continuing.

Read the reflog with dates and all local references

git reflog --date=local --all

A simplified result can look like this:

a1b2c3d HEAD@{0}: reset: moving to HEAD~1
e5f6a7b HEAD@{1}: commit: Add checkout layout
9a8b7c6 HEAD@{2}: checkout: moving from main to dev

The commit on the line before a destructive move is often the candidate, but do not recover it based only on position. Reflogs can contain checkouts, rebases, merges, pulls, amendments, and branch updates.

Inspect the candidate commit

git show --stat --summary e5f6a7b
git show e5f6a7b

Check the author, date, commit message, parents, and changed files. When the repository is large, compare more than one candidate. A familiar commit message is not enough if several commits used similar wording.

Create a rescue branch instead of moving the current branch

git switch -c rescue-checkout-layout e5f6a7b

For older Git versions:

git checkout -b rescue-checkout-layout e5f6a7b

This attaches the recovered commit to a named branch. Run the project’s normal tests or open the affected files before merging or cherry-picking anything into the intended branch.

Recover a deleted branch without switching to it

git branch recovered-work e5f6a7b

Then confirm where the recovered branch points:

git log -1 --oneline --decorate recovered-work
git branch --contains e5f6a7b

Choose how to restore the work

• Keep the rescue branch: useful when several commits or an entire line of work must be reviewed.
• Cherry-pick one commit: use after switching to the correct destination branch and confirming the commit is self-contained.
• Merge the rescue branch: appropriate when the recovered branch history should remain intact.
• Move an existing branch: do this only after backup and review; it is not the first recovery step.

Check the remote before assuming the commit is lost

If the branch was pushed earlier, fetch remote references and inspect them:

git fetch --all --prune
git branch -a --contains e5f6a7b

A remote branch, pull request, or teammate’s clone may contain the work even when your local reflog does not. Reflogs themselves are normally local and are not transferred by push or fetch.

Understand the recovery window

Git’s official documentation describes reflog expiration settings and notes that reachable entries commonly expire later than unreachable entries. Defaults can be changed by repository or global configuration, so do not assume every entry remains available indefinitely. The longer you wait—and the more cleanup that occurs—the less reliable reflog recovery becomes.

If the commit is not in the reflog

• Run git reflog --all and inspect branch-specific reflogs.
• Check local stashes with git stash list.
• Check remote branches, pull requests, CI artifacts, release tags, and another clone.
• Use editor local history or backups for work that was never committed.
• Do not copy random object files from .git/objects without understanding the repository state.

Confirm the recovery before deleting anything

1. Open the recovered files and run the project’s normal tests.
2. Confirm the branch contains the expected commits and no unrelated history.
3. Push the rescue branch if the remote is an appropriate additional copy.
4. Only then clean up temporary branches or continue the interrupted rewrite.

Official Git references

• git-reflog documentation
• git-gc documentation