Recover commits lost during a rebase

Does this match your situation?

• A rebase finished but commits are missing from git log.
• You resolved conflicts wrongly and want to start over.
• You dropped or squashed a commit in interactive rebase by accident.
• A rebase is stuck partway and you want out.

Step-by-step fix

1. Still mid-rebase? Abort it

   If Git is still in the middle of the rebase, aborting restores the original branch completely. Nothing is lost and you can try again.

   step 1Copy

   git rebase --abort
   

2. Rebase finished badly? Use ORIG_HEAD

   Git writes the branch's previous tip into ORIG_HEAD before any rebase, merge or reset. That makes recovery from a just-completed rebase a single command.

   step 2Copy

   git reset --hard ORIG_HEAD
   

   ✅ORIG_HEAD is overwritten by the next rebase, merge or reset — so use it right away or grab the hash from the reflog instead.

3. Otherwise, read the reflog

   The reflog logs every step the rebase took. Look for the entry immediately before the 'rebase (start)' line — that's your original branch tip.

   step 3Copy

   git reflog
   
   # typical output:
   # a1b2c3d HEAD@{0}: rebase (finish): returning to refs/heads/feature
   # f4e5d6c HEAD@{5}: rebase (start): checkout main
   # 9a8b7c6 HEAD@{6}: commit: The work you want back   ← this one
   

4. Restore onto a branch you can compare

   Rather than resetting immediately, create a branch at the recovered commit. You can then diff it against the rebased branch and keep whichever is right.

   step 4Copy

   git branch pre-rebase 9a8b7c6
   git log --oneline pre-rebase -10
   git diff pre-rebase feature
   
   # happy with it? point your branch back:
   git switch feature
   git reset --hard pre-rebase
   

5. Recover a single dropped commit

   If the rebase was mostly right and you only lost one commit, cherry-pick it back rather than resetting everything.

   step 5Copy

   git cherry-pick 9a8b7c6
   

Why this works

Rebase never edits commits — it creates new ones with the same changes and different parents, then moves the branch pointer to the new chain. The originals become unreferenced but remain in .git/objects, and every step is journalled in the reflog. ORIG_HEAD is a convenience reference Git sets to the previous tip before any operation that moves the branch significantly, which is why it so often points exactly where you want to go.

If that didn’t work

• Run git fsck --lost-found and look through dangling commits with git log --oneline <hash>.
• If the branch was pushed before the rebase, git fetch origin and recover from origin/your-branch.
• Check whether a colleague or CI still has the pre-rebase commits.

How to stop it happening again

• Create a safety branch before rebasing: git branch backup-$(date +%s).
• Use git rebase --autostash so uncommitted work isn't in the firing line.
• Never rebase a branch that's already shared — merge it instead.
• Turn on rerere so repeated conflict resolutions replay themselves.

Commands used in this guide

Frequently asked questions