Revert a merge commit that has already been pushed

Use git revert -m PARENT_NUMBER MERGE_COMMIT to reverse a merge's net change relative to a chosen parent. This creates a new commit and preserves the shared history. Parent one is often the target branch's pre-merge tip, but verify it before acting.

Identify the merge and mainline

git log --oneline --graph
git show --no-patch --format='%H%n%P%n%s' a1b2c3d
git diff a1b2c3d^1 a1b2c3d

The %P line lists parents in order. A normal two-parent merge made while on main usually has the old mainline as parent one; merges can also have more than two parents. The diff shows the effect you are proposing to reverse.

With a clean working tree and the intended parent confirmed:

git revert -m 1 a1b2c3d

Review the resulting commit, run tests, and submit it through the team's usual push or pull-request workflow. Revert preserves commit ancestry, but it can still conflict or introduce an application-level regression.

Resolve conflicts

Later changes may overlap the merge's original effect. Resolve the files, stage the result, and run git revert --continue. To abandon an active operation, use git revert --abort. Switching to rebase is not a substitute for deciding what the rollback should contain.

Understand what happens to a later merge

Reverting the merge changes files; it does not remove the original merge or its ancestors. Merging the same feature tip again can therefore report “Already up to date.” New commits on that feature branch may merge, but earlier reverted changes do not automatically return.

One approach is to reverse the revert, then integrate any new feature work:

git revert REVERT_COMMIT
git merge feature-x

Replace REVERT_COMMIT with the actual corrective commit ID. Reversing it may conflict with subsequent mainline changes, so review and test the combined result.

Another approach is to create a fresh branch from current main and reimplement or selectively replay the intended changes as new commits. Simply running git rebase main on the old feature branch does not guarantee this: commits already reachable through the original merge need not be replayed.

Choose rollback boundaries deliberately

A reset followed by a forced push can remove the merge from a branch's visible history, but that requires a coordinated history rewrite and can disrupt collaborators. A corrective revert is generally the appropriate shared-branch operation. If you need only part of the rollback, a narrowly scoped corrective change may be easier to reason about than reversing an entire feature.

See git-revert and the Git guide to reverting a faulty merge.