Introduction

During an interactive rebase (git rebase -i), it is easy to accidentally drop a commit by removing it from the todo list, changing its command to something unexpected, or encountering a conflict that causes the rebase to skip it. The dropped commit disappears from the branch history:

bash
git log --oneline
# Expected 5 commits, but only 3 appear after rebase

The good news is that Git almost never truly loses commits - they are still accessible through the reflog.

Symptoms

  • Commits missing from git log after rebase
  • Commit history shorter than expected
  • Code changes from dropped commit are gone
  • Rebase completed with a message about dropped commits
  • Conflicts during rebase caused some commits to be skipped

Common Causes

  • Accidentally deleting a line from the rebase todo editor
  • Changing pick to an unrecognized command, causing Git to skip it
  • Conflict resolution during rebase that led to git rebase --skip
  • Squash combining commits incorrectly, losing one commit's changes
  • Rebase range specified incorrectly, excluding commits

Step-by-Step Fix

  1. 1.Find the dropped commit using reflog:
  2. 2.```bash
  3. 3.git reflog
  4. 4.# Look for the commit hash before the rebase
  5. 5.# Example: abc1234 HEAD@{2}: rebase (finish): returning to refs/heads/main
  6. 6.`
  7. 7.Compare the current branch with the pre-rebase state:
  8. 8.```bash
  9. 9.git diff HEAD@{1} HEAD --stat
  10. 10.# Shows what was lost during the rebase
  11. 11.`
  12. 12.Cherry-pick the dropped commit:
  13. 13.```bash
  14. 14.# Find the dropped commit's hash
  15. 15.git log --oneline HEAD@{1} --not HEAD
  16. 16.# Cherry-pick it onto the current branch
  17. 17.git cherry-pick <dropped-commit-hash>
  18. 18.`
  19. 19.If the rebase is still in progress, you can edit the todo list:
  20. 20.```bash
  21. 21.git rebase --edit-todo
  22. 22.`
  23. 23.Add back the missing commit line with pick or squash, then:
  24. 24.```bash
  25. 25.git rebase --continue
  26. 26.`
  27. 27.Abort the rebase and start over if too many commits were dropped:
  28. 28.```bash
  29. 29.git rebase --abort
  30. 30.# Then re-run with a more careful todo list
  31. 31.git rebase -i HEAD~5
  32. 32.`

Prevention

  • Always create a backup branch before interactive rebase: git branch backup-before-rebase
  • Use git log --oneline before and after rebase to verify commit count
  • Leave comments in the rebase todo editor (lines starting with #) to document your plan
  • Use fixup instead of squash when you do not need to edit the combined commit message
  • For complex rebases, do them in stages rather than one large rebase
  • Use git rerere (reuse recorded resolution) to avoid re-resolving the same conflicts
  • Consider using git rebase --autosquash with properly formatted commit messages
  • Review the rebase todo list carefully before saving - every line matters