Recovery
Recover after a bad rebase
When rebase introduces conflicts, missing commits, or a result you no longer trust, stop rewriting history and recover control with abort, reflog, and rescue branches.
- Anyone actively handling a Git mistake
- Readers who want a conservative rescue habit before trouble happens
- Stop mutating the repo further
- Be ready to inspect `git reflog`, `git status`, and `git log --graph`
- Running more reset or rebase commands before preserving a checkpoint
- Changing shared history before assessing blast radius
The main mistake is usually continuing blindly
When people see conflicts, strange ordering, or “missing” commits after a rebase, they often respond by trying more rebase, reset, and checkout commands in panic.
The safer move is to stop and preserve the last trustworthy state first.
Separate two situations
Situation 1: the rebase is still in progress
Git will usually tell you that you can:
git rebase --continuegit rebase --skipgit rebase --abort
If you no longer trust the intermediate state, --abort is usually the safest option.
Situation 2: the rebase finished, but the result looks wrong
That is when reflog matters most:
git reflog
Find the position from before the rebase and create a rescue branch:
git switch -c rescue/pre-rebase HEAD@{3}
Why commits appear to vanish
Rebase does not “move” the old commit objects. It replays your work on a new base and creates new commits.
That means:
- commit IDs change
- parent relationships change
- old commits may still exist for a while, but your branch no longer points to them
So the problem is often “the name moved,” not “the data was instantly deleted.”
A conservative recovery flow
git status
git log --oneline --graph --decorate -n 30
git reflog
git switch -c rescue/pre-rebase <old-commit>
Then choose one of three paths:
- go back to the pre-rebase state
- rescue only a subset of commits
- restart the rebase more carefully
When git rebase --abort is the right choice
Prefer --abort when:
- the rebase is still active
- you no longer know which conflict you are resolving
- you are unsure whether
skipwould drop meaningful work - this was only local cleanup and not worth gambling on
When to create a rescue branch first
If the rebase already finished and you want to compare “before” and “after,” create a rescue branch first.
Its job is not to fix everything immediately. Its job is to preserve evidence and a known-good checkpoint.
One practical rule
After a bad rebase, the first goal is not “get to push again quickly.”
The first goal is “return to a state I can explain.”