You ran git revert abc1234 to undo a bad merge and Git printed error: commit abc1234 is a merge but no -m option was given. You are not sure what -m means, which number to pass (1 or 2?), or whether reverting a merge commit will actually remove all the changes that came in with it. Merge commits have two parents — the branch that was merged from, and the branch that was merged into — and Git needs to know which parent represents the “mainline” in order to compute what to revert. Getting -m wrong produces a revert that either does nothing visible or reverts the wrong set of changes.
Common causes
Ordered by hit rate, highest first.
1. Running git revert on a merge commit without -m
git revert works by computing a diff between a commit and its parent, then applying the inverse. Merge commits have two parents, so the diff is ambiguous without specifying which parent is the baseline.
How to spot it: The error message itself: error: commit is a merge but no -m option was given.
2. Using -m 2 when you meant -m 1 (or vice versa)
-m 1 reverts the merge by treating parent 1 (the branch the merge landed on, usually main) as the mainline. -m 2 treats parent 2 (the feature branch) as the mainline — this reverts in the opposite direction and is almost never what you want when reverting a PR merge.
How to spot it: After the revert, git log --oneline main | head -5 shows a revert commit but git diff main~1 main shows changes going in the wrong direction.
3. Reverting a squash-and-merge vs. a true merge commit
When GitHub’s “Squash and merge” is used, there is no merge commit — it is a regular commit, and git revert <sha> works without -m. Developers familiar with “Create a merge commit” mode may run -m 1 unnecessarily on a squash merge, which Git simply ignores.
How to spot it: git show --format="%P" <sha> | wc -w — if it returns 2, it is a true merge commit. If it returns 1, it is a squash or regular commit.
4. Re-merging the same branch after reverting the merge
The team reverted a merge, fixed the bugs, and then tried to re-merge the same feature branch. The re-merge appears as an empty commit because the revert commit already exists in main’s history, and Git considers the feature branch already “applied and then reverted.” The re-merge does not bring the original commits back.
How to spot it: After re-merging, git diff main~1 main shows the expected changes are absent. The feature branch commits are present in history but their changes are not reflected in the working tree.
5. Octopus merge commit with 3+ parents
Some advanced workflows (or automated merge trains) produce octopus merges with three or more parents. git revert -m 1 reverts to the first parent, but the correct mainline may be a different parent index.
How to spot it: git show --format="%P" <sha> returns three or more SHAs.
Shortest path to fix
Step 1: Identify the merge commit parents
git show --format="%H %P %s" --no-patch abc1234This prints the commit SHA, parent SHAs, and subject. Parent 1 is typically main; parent 2 is the feature branch.
To see branch names associated with parents:
git log --oneline --decorate abc1234^1 -1 # parent 1
git log --oneline --decorate abc1234^2 -1 # parent 2Step 2: Revert the merge commit with the correct parent
For a standard PR merge where feature was merged into main:
git revert -m 1 abc1234This creates an inverse commit that undoes everything the feature branch introduced, keeping main’s history as the baseline.
Step 3: Verify the revert removed the intended changes
git log --oneline -5
git diff HEAD~1 HEAD # should show the inverse of the original merge diffCheck that the reverted code is gone from the working tree:
git show HEAD --stat # shows which files the revert touchedStep 4: Re-merge after fixing the underlying problem
When the feature is ready to re-merge after a bug fix, you must first revert the revert:
git revert HEAD # reverts the revert commit (restores the original feature changes)
# Now merge the fixed feature branch
git merge feature/fixed-login --no-ffSkipping the “revert the revert” step causes the re-merge to appear empty.
Step 5: Handle an octopus merge
# List all parents with their positions
git cat-file -p abc1234 | grep "^parent"
# parent 1: <sha-of-main>
# parent 2: <sha-of-branch-a>
# parent 3: <sha-of-branch-b>
# Revert treating parent 1 (main) as mainline
git revert -m 1 abc1234Prevention
- Always use
--no-ffwhen merging feature branches so merges always produce a merge commit (not a fast-forward) that can be reverted with-m 1. - Document team conventions in
CONTRIBUTING.md: “When reverting a merge from a PR, always usegit revert -m 1.” - Prefer squash-and-merge for small PRs — a single squash commit can be reverted without
-mand is easier to reason about. - If a feature needs to be removed temporarily, consider using a feature flag instead of reverting — reverts in long-lived branches create confusing history and complicate re-merges.
- Test your revert in a sandbox branch before applying to
main:git switch -c sandbox/test-revert && git revert -m 1 abc1234— verify the result, then merge the sandbox branch. - Use
git log --merges --oneline -10to identify merge commits quickly when you need to target one for reversion.
FAQ
Q: Why does -m 1 usually mean “keep main” and -m 2 mean “keep the feature branch”?
A: When you run git merge feature on main, the resulting merge commit’s parent 1 is the commit on main that was HEAD at merge time, and parent 2 is the tip of the feature branch. Reverting with -m 1 means “restore to what parent 1 looked like” — i.e., restore main to before the merge.
Q: After reverting a merge, I re-merged the same branch and got an empty commit. Why?
A: The revert commit is now in the feature branch’s ancestry via main. Git sees the feature commits as “already reachable” and produces no net diff. Always revert the revert first, then re-merge.
Q: Can I revert individual commits from a merged feature branch instead of the whole merge?
A: Yes. Use git log --oneline abc1234^2..abc1234 to list commits from the feature branch, then cherry-pick the revert of specific commits: git revert <commit-sha> for each one individually.
Q: Does reverting a merge commit delete the feature branch?
A: No. The feature branch still exists and its commits are still in the object store. Reverting only adds a new commit to main that undoes the net changes — it does not modify or delete the feature branch or its history.