Recover after an accidental merge

What you will learn

• Understand the core purpose of Recover after an accidental merge
• Master the basic usage and common options of 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.
• Understand key concepts: Key checks
• Know when to use this feature and when to avoid it

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

Start with a problem

You just ran a Git command and the result wasn't what you expected — maybe you even lost some commits. This has happened before, and you want a reliable set of recovery techniques.

Key checks

1. Has the merge commit been pushed?
2. Has anyone branched from it?

Assessment

Merge timePushed or notAffected file count

→assess → choose strategy

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

Try it yourself

1. Practice the recover-after-accidental-merge command in a test repository and observe state changes before and after
2. Experiment with different options and compare the output differences
3. Simulate a real scenario where you would need to use this, and walk through the full process

Further reading

Keep going on the same topic:

• Fixing wrong author or commit message after commit
• How to recover from a failed cherry-pick
• Recover after an accidental git clean