How to recover lost Git work with reflog.
If a commit disappeared after reset, rebase, branch deletion, or checkout, do not panic and do not keep rewriting history. Git reflog often still knows where HEAD or a branch used to point.
First rule: stop making the state noisier
Recovery gets harder when you continue rebasing, resetting, cleaning, or force pushing while unsure what happened. Start by inspecting. The goal is to find the old commit, create a rescue branch, and only then decide how to integrate it.
1. Inspect reflog
Run git reflog and look for the entry before the reset, rebase, checkout, or branch move.
2. Verify the commit
Use git show <sha> or a visual history view to confirm the missing work is there.
3. Create a rescue branch
Run git branch rescue-lost-work <sha> before attempting cherry-pick, merge, or reset.
Common recovery cases
- After
git reset --hard, reflog can point to the commit HEAD referenced before the reset. - After an interactive rebase, reflog can show the pre-rebase branch tip and intermediate states.
- After deleting a branch, reflog may still expose commits that were only reachable from that branch.
- After checking out another branch, reflog helps find where HEAD was before the move.
What reflog does not guarantee
Reflog is local and time-limited. It is not a backup system, and it may not save uncommitted file content discarded from the working tree. That is why safer Git tooling should warn before destructive operations and encourage rescue branches before risky experiments.
Make recovery visible before it becomes a crisis.
FluxGit surfaces recovery-oriented workflows around risky operations. The private beta is Windows first, local-first, and designed so repository data is not sent by default.