Introduction

A bad merge usually means the merge commit itself is wrong, but some later commits on top of it are still worth keeping. The clean repair strategy is to rebuild the merge from the last good point, then replay only the good follow-up commits onto that corrected history.

Identify the Bad Merge and the Good Commits

Start by looking at the recent history so you know:

• The bad merge commit
• The commit just before that merge
• The later commits you want to keep

git log --graph --oneline --decorate --all

Assume the history looks like this:

• 'A is the last good commit before the bad merge'
• 'M is the bad merge'
• 'C1 and C2 are good commits made afterward'

That means you want a new history shaped like: rebuild merge after A, then replay C1 and C2.

Rebuild the Merge on a Repair Branch

Create a new branch from the commit before the bad merge:

git switch -c repair A
git merge feature-branch

Resolve the conflicts carefully this time, run tests, and complete the merge. This creates a replacement merge commit that represents the history you actually wanted.

If the original bad merge came from the wrong merge base or a rushed conflict resolution, this step gives you a clean place to fix that mistake instead of trying to patch over it afterward.

Replay the Good Commits

Once the corrected merge exists on repair, replay the good commits with cherry-pick:

git cherry-pick C1
git cherry-pick C2

If the good commits are consecutive, you can cherry-pick a range:

git cherry-pick C1^..C2

Now the repair branch contains:

1. The corrected merge
2. The later work you still wanted to keep

This is usually much easier to reason about than trying to undo pieces of a broken merge in place.

Replace the Broken History Safely

What you do next depends on whether the bad merge is already shared.

If the bad merge is local or unpublished, you can move the target branch to the repaired history:

git switch main
git reset --hard repair

If the bad merge is already on a shared branch, avoid rewriting shared history unless your team explicitly agrees to it. In that case, it is often safer to revert the bad merge on the shared branch and then merge or cherry-pick the repaired work.

git switch main
git revert -m 1 M
git merge repair

The -m 1 option tells Git which parent of the merge should be treated as the mainline when producing the revert.

Why Not Just Revert Everything Manually

Manual fix-up commits on top of a bad merge often leave the repository in a state that "works" but is hard to understand later. Rebuilding the merge from the correct base has two advantages:

• The history explains what really happened
• Future merges are less likely to be confused by half-reverted merge state

This matters especially when the merged branch will continue evolving after the repair.

Common Pitfalls

• Cherry-picking commits that depend on the broken merge can create new conflicts. Read each commit before replaying it.
• Rewriting shared history with reset --hard is dangerous unless the branch is private or the team has coordinated the force-push.
• Forgetting -m 1 when reverting a merge produces confusing results because Git needs to know which parent is the mainline.
• Repairing directly on the shared branch instead of on a temporary branch removes your safety net if the fix needs another attempt.

Summary

• Find the last good commit before the bad merge, then create a repair branch from there.
• Rebuild the merge cleanly and verify it before replaying later commits.
• Use git cherry-pick to keep only the good follow-up commits.
• Replace local history with a reset, or use a revert-based repair path when the bad merge is already shared.