Git Reflog: Find Commits After a Reset or Rebase

After a reset or rebase, a recent commit may disappear from the current branch's history without its data having been deleted. Git reflog can help locate previous reference positions in the local repository so you can identify a commit worth preserving.

1. Commit history and reflog answer different questions

git log normally follows history from the current commit. The git-reflog manual explains that reflogs record local reference updates; the HEAD reflog also records branch switches. This can reveal commits outside the history you are currently viewing.

A reflog is not shared team history and is not synchronized like commits through push and pull. Inspect the repository copy where the operation occurred.

2. Pause changes and inspect the current state

This workflow locates existing commits, not every uncommitted edit. Avoid further resets or Git cleanup operations while investigating.

git status --short
git reflog show HEAD -n 20

The first command identifies working changes and untracked files. Preserve that work using an appropriate backup before switching branches or restoring files. Do not overwrite it merely to obtain a clean directory.

Read both commit identifiers and operation descriptions. The entry before the newest one is not automatically the version you need: multiple switches, commits or rebase steps may have happened since then.

3. Verify a candidate commit

Suppose you find abc1234. This is only an illustrative identifier; replace it with a real one from your repository:

git show --stat abc1234
git show abc1234 -- src/Example.php

git show displays commit information and associated changes. Check the author, message, affected paths and actual edits. Merge commits have distinct diff-display behavior, so an unexpected lack of diff output alone is not conclusive.

To inspect the complete file at that commit without replacing the working copy:

git show abc1234:src/Example.php

The path is repository-root relative and must exist in the selected commit. Finding the right filename is insufficient; verify the changes you actually need.

4. Create a rescue branch before reintegration

git branch rescue/recovered-work abc1234
git log -1 --oneline rescue/recovered-work
git status --short

As the git-branch manual describes, this creates a branch without switching to it. It names the verified commit without requiring a working-tree overwrite. If the branch name exists, choose another name rather than forcing an overwrite.

You now have a branch referencing the commit. Decide whether to reintegrate a branch, one commit or selected changes. Merge and cherry-pick can conflict; preserve current work and inspect the history relationship before using them. A local rescue does not require a force-push.

5. Understand the limits

• Reflog does not back up every editor keystroke. This workflow cannot recover content that Git never stored as an object.
• Reflog entries can expire and unretained objects can be pruned. Recovery is not guaranteed indefinitely.
• A new clone does not inherit another clone's local reflog.
• Locating a commit does not prove a complete feature has been recovered. Test before handing it off.

6. Completion checklist

Confirm that the correct commit has a rescue branch, uncommitted edits remain preserved and the integration approach has been reviewed. Then follow the project's review, testing and backup process. Reflog provides a verifiable path back, not a promise that every Git operation can be undone.