Incident: a bad merge

First diagnose: find the exact commit that broke main. Do not guess — read the graph. The merge commit is the one with two parents sitting where main went red:

git fetch origin
git log --graph --oneline --decorate origin/main | head -30
git show <merge-sha>          # see what was merged and the parent line

git show on a merge prints the combined diff and, crucially, the parent list (Merge: a1b2c3 d4e5f6). The first parent is the branch you were on when the merge happened — main — and the second is the feature branch that got pulled in. That parent order is what the revert in step 3 depends on.

Decide the tool by one question: is this history pushed and shared? This is the whole decision tree, and it is binary:

• Shared / already pushed (the bad merge is on origin/main): you must append a correction, never rewrite. Use git revert.
• Local-only (the merge exists only on your machine, never pushed): you may rewrite freely. git reset --hard <before-merge> is fine.

On a team incident the answer is almost always “shared,” because the merge is on origin/main and teammates have already fetched it. Rewriting it with reset + force-push would erase commits other people now build on and desync every clone. Revert keeps the bad merge in history and lands a new commit that undoes its effect.

Revert the merge with -m 1 to name the mainline parent. A merge has two parents, so git revert cannot know which side is “the change to undo” — you must tell it with -m (mainline). -m 1 means “keep the first parent (main) as the baseline and undo everything the second parent brought in”:

git revert -m 1 <merge-sha>
git push origin main          # ordinary push: revert is a new commit, no force

This appends one new commit that subtracts the feature’s changes. main is green again, the full history is preserved, and nobody’s clone is invalidated. Picking the wrong mainline (-m 2) would undo main’s own work instead — so confirm the parent order from step 1 first.

If a force-push erased commits, recover them with reflog — the safety net for shared disasters. Suppose someone “fixed” the incident by force-pushing and wiped good commits off main. Those commits are not gone; they are unreferenced, and the reflog still names them on any machine that had them:

git reflog                    # local: every position HEAD has held, with shas
git reflog show origin/main   # what the remote-tracking ref pointed to over time
git branch rescue <good-sha>  # re-anchor the lost commits onto a real branch

The reflog is per-clone and local, so the recovery often happens on a colleague’s clone (or the server’s own reflog / git fsck --lost-found) that still holds the pre-force-push tip. Find the last good SHA there, branch it, push it, and the lost work is back. Reflog is why “I force-pushed over good work” is recoverable rather than fatal.

Communicate, then re-land the fix cleanly. Technical recovery is half the job. Post in the incident channel what happened, what you reverted, and that main is green. Then bring the feature back the right way: branch off the fresh main, revert-the-revert or rebase the original work onto it, fix the actual defect, run CI to green, and merge through a normal reviewed PR. The incident ends not when main builds again but when the feature lands correctly and the team knows the sequence.