Recovery

Recover after an accidental merge

When the wrong branch was merged, decide between reset and revert -m based on sharing state, and undo the merge safely without damaging collaboration history.

Who This Is For
  • Anyone actively handling a Git mistake
  • Readers who want a conservative rescue habit before trouble happens
Prerequisites
  • Stop mutating the repo further
  • Be ready to inspect `git reflog`, `git status`, and `git log --graph`
Common Risks
  • Running more reset or rebase commands before preserving a checkpoint
  • Changing shared history before assessing blast radius

Most merge-recovery mistakes happen when teams use reset where revert -m is required.

Key checks

  1. Has the merge commit been pushed?
  2. Has anyone branched from it?
Recover After Accidental MergeDon't panic after an accidental merge. Assess impact scope first, then choose rollback or reset.
Assessment
Merge timePushed or notAffected file count
Recovery Strategy
git reset --mergegit revertgit reflog
If already pushed to a shared branch, do not reset; use revert instead.

First inspection

git log --oneline --graph --decorate -n 20
git branch -vv
git reflog

Recovery options

Merge not shared

git reset --hard HEAD~1

Merge already shared

git revert -m 1 <merge-commit>

-m 1 keeps the first-parent perspective.

Confirm parent selection before `revert -m`

Choosing the wrong parent can revert the wrong side of history and create additional recovery work.

Good follow-up reads

  1. undo after pull
  2. assess force-push impact
  3. git-merge