Reverting a Merge Commit (and Getting the Feature Back)

Reverting a normal commit is a one-liner. Reverting a merge commit - the one that brought a whole feature branch into main - needs an extra decision, and it plants a trap for later. Both are manageable once you know they exist.

The -m flag#

A merge commit has two parents, so Git cannot know which side’s changes to undo:

git revert -m 1 6d12f5a

-m 1 says “treat parent 1 as the main line” - the branch you merged into, which is main for an ordinary PR merge. The revert undoes everything the feature branch added, in a single new commit. The whole feature is out of main, history untouched, nobody re-pulls a rewritten branch.

The trap: the feature will not come back on its own#

Weeks later the feature is fixed and you merge the branch again - and the merge brings almost nothing. From Git’s point of view those commits are already merged: their ancestry is in main, so a new merge sees no new commits. The fact that a later revert undid their changes is content, not ancestry, and merges do not look at content.

This is the confusing part: the branch is “merged”, main lacks the code, and nothing looks wrong until the deploy.

The two ways back#

Revert the revert. The clean route:

git revert 52ed808   # the commit that reverted the merge

Now main has the feature’s changes again, and merging the branch brings only what is genuinely new. The history reads oddly - merge, revert, revert-of-revert - but it is accurate, and accuracy beats tidy here.

Rebase the branch. If the branch is still yours and unpushed elsewhere, rebase it onto current main. The rebased commits get new hashes, so the next merge sees them as new work. This hides the oddity but rewrites the branch, with the usual force-push-with-lease implications if it was shared.

For a small team, revert-the-revert is usually right: no rewriting, and the paper trail explains the whole episode to the next person who reads git log.

When to reach for it#

Reverting the merge is the right move when the whole feature has to leave main quickly - a bad release, a pulled launch - and you want it out in one reviewable commit. If only one change inside the feature is bad, revert that specific commit instead and leave the merge alone: surgical beats sweeping whenever it is an option.