A bad git rebase can drop commits, overwrite changes, and shatter the sequence your team depends on. When it happens, you need a clear, repeatable incident response plan that restores the repository and protects production code.
Identify the damage fast.
Start with git reflog. This is your timeline of branch state. Each entry is a recovery point. Locate the last known good commit. Confirm it against your CI logs or deploy records.
Isolate the branch.
Do not keep working in the damaged branch. Create a new branch from the safe commit. Names matter in incident response—choose something obvious like recovery/<incident-id>.
Recover lost commits.
Use git cherry-pick from the reflog or from team members’ local clones. Conflicts will happen—resolve them with precision, no partial fixes.
Verify integrity before merging.
Run tests locally and in CI. Check code review diffs to ensure nothing was silently dropped. Compare against backups or mirrors if your org keeps them.
Restore normal workflow.
Merge the recovery branch back into trunk. Communicate the incident clearly in your changelog or internal channels. This helps future investigation if artifacts show up later.
Prevent recurrence.
Audit your rebase practices. Enforce --interactive and ensure developers understand the commit sequence. Maintain robust backups and consider gated branch protection.
Git rebase incident response is a muscle: practice it before disaster hits. The faster you can diagnose, isolate, recover, verify, and restore, the less damage lingers in your history.
See real-time rebase incident response in action—deploy a live sandbox with hoop.dev in minutes.