How to Revert a Merge Commit in Git

To undo a merge commit that is already part of shared history, use git revert -m. The -moption tells Git which parent is the mainline to keep; it does not mean “merge number one.” Inspect the commit's parents before running the revert, then review and test the resulting changes.

What does reverting a merge commit do?

A merge commit has two or more parents. A normal git revert needs a single parent to compare against, so reverting a merge requires you to select the parent whose line of history should remain the mainline. Git then creates a new commit that reverses the changes introduced by the merge relative to that parent. The original merge and its commits remain in history.

This is usually safer than resetting a branch that other people use, because it does not remove or replace existing commit IDs. If the merge is not shared and has not been pushed, you may instead want to undo the merge by moving your local branch back; see how to undo a Git merge.

1. Find and inspect the merge commit

Find the merge commit you intend to undo and inspect its parents:

git log --oneline --graph --decorate
git show --no-patch --pretty=raw <merge-commit>

Replace <merge-commit> with the merge commit hash. Its raw output lists the parent commit IDs in order. Parent 1 is typically the branch that was checked out when the merge was made; parent 2 is typically the branch that was merged in. Verify the history rather than assuming which branch each parent represents.

2. Choose the mainline parent

The mainline is the parent whose history you want to keep. For example, if the merge brought a feature branch into main and you want to keep the mainline while undoing the feature's contribution, the mainline is usually parent 1. Confirm this from the parent list and the graph before proceeding.

The number passed to -mis the parent's position, starting at 1. It is not a commit hash and it does not refer to a branch name. Choosing the wrong parent can reverse a different set of changes than intended.

3. Revert the merge and review the result

If inspection confirms parent 1 is the mainline you want to keep, run:

git revert -m 1 <merge-commit>

Replace the placeholder with the verified merge commit ID. Git creates a new revert commit, usually opening your editor for a commit message. Inspect the result and run the relevant tests before pushing:

git status
git show --stat HEAD
git diff HEAD^ HEAD

Review the files and behavior affected by the revert. A revert reverses the merge's changes relative to the selected mainline; it does not guarantee that later commits or unrelated edits are removed.

Resolve conflicts during the revert

Later changes may conflict with the changes being reverted. If Git stops with conflicts, inspect the files, resolve each conflict, and stage the resolutions:

git status
git add -- path/to/resolved-file
git revert --continue

To cancel the revert operation before it completes, use git revert --abort. Read Git's conflict status carefully and avoid staging unrelated changes.

Reverting a merge does not erase its history

The merge commit remains an ancestor of the branch after a revert. This means a later merge of the same branch may not bring back the reverted changes automatically: Git sees those commits as already merged. If the changes need to be restored, teams commonly revert the revert commit or create new commits with the desired changes. Review the branch graph and coordinate with collaborators before merging again.

Frequently asked questions

Why does Git require -m for a merge revert?

A merge has multiple parents, so Git needs to know which parent is the mainline for calculating the inverse changes. The -m option provides that parent number.

Should I reset or revert a pushed merge commit?

Revert is the normal choice for a merge that is already shared. It preserves the existing history and adds a commit that reverses the merge's changes. Reset rewrites the branch and can disrupt collaborators.