How to Recover Lost Commits with git reflog

A reset, rebase, amend, or deleted branch can make a commit seem missing even though Git may still remember where your branch or HEAD pointed. The local reference log, git reflog, can help you find that commit. Start by inspecting history and creating a rescue branch before attempting a reset.

What does the Git reflog record?

Git maintains a local log of recent updates to references, including where HEAD and branches pointed. Unlike git log, which shows commits reachable from the current history, the reflog can show earlier positions that are no longer reachable from a branch. It is local to your repository and is not a shared or permanent backup.

1. Find the missing commit in the reflog

List recent HEAD movements, optionally showing readable timestamps:

git reflog --date=local

Output entries include a short commit ID and an action, for example a reset, rebase, checkout, or commit. Look for the entry from just before the commit disappeared. You can also inspect one branch's reflog:

git reflog show main

The exact entries depend on what happened. If you know roughly when the commit existed, use the action, timestamp, and commit message as clues rather than assuming the newest reflog entry is the one you need.

2. Inspect the candidate commit

Before moving any branch, confirm that the candidate commit contains the expected work:

git show --stat <commit-id>
git show --oneline --decorate <commit-id>

Replace <commit-id> with the hash from the reflog. Inspect the commit message and changed files to avoid recovering the wrong point in history.

3. Preserve the commit on a rescue branch

The safest first step is to create a branch at the commit. This gives it a reachable name without changing your current branch or working tree:

git branch rescue-lost-work <commit-id>

You can then inspect that branch without immediately changing your current branch:

git log --oneline --decorate rescue-lost-work

If you want to work from the recovered commit as a new branch, use git switch rescue-lost-work. Creating the branch first ensures the commit remains reachable even if you continue other work.

Restore the commit to an existing branch

If you need the changes on your current branch, you can often apply the recovered commit with cherry-pick rather than moving the branch pointer backward:

git cherry-pick <commit-id>

Check git status first and save any uncommitted work. Cherry-picking creates a new commit with the selected changes; it can produce conflicts, which you must resolve before completing the operation. If several commits are missing, inspect their order and apply only the commits you intend to restore.

Should you reset the branch to the old commit?

Resetting changes the current branch pointer and may replace files in your working tree. Do not use git reset --hard as a first recovery step. If you deliberately need to move a branch, back it up first and ensure you understand which commits and local edits will be affected:

git status
git branch backup-before-recovery
git reset --hard <commit-id>

This example is intentionally destructive: the final command resets the current branch and discards uncommitted working-tree changes. Only run it when you specifically intend to replace the current branch state and have protected any work you need. If the branch has already been pushed, coordinate with collaborators before rewriting shared history.

If the commit is not in the reflog

Reflog entries expire according to Git's settings, and unreachable objects may eventually be pruned. If the reflog has no useful entry, a repository administrator or another clone may still have the commit. Advanced users can also inspect unreachable objects with git fsck --no-reflogs --unreachable, but that output may be difficult to identify and is not a guarantee of recovery. The reflog is local, so check the repository where the lost work was created.

Git reflog recovery FAQ

Can git reflog recover a commit after git reset --hard?

Often, if the commit is still recorded in the local reflog and its Git object has not been pruned. Find the entry, inspect the commit, and create a rescue branch before changing history again.

Does git reflog show commits from every clone?

No. Reflogs are stored locally. Another clone may have different reflog entries, and a fresh clone will not automatically contain your local reference history.