Comprehensive Guide to Reverting Pushed Merge Commits in Git

Technical Background of Merge Commit Reversion

In distributed version control systems, merge operations form the core of code collaboration. When modifications from two branches are integrated, Git creates a special merge commit containing multiple parent nodes, each pointing to the latest state of the merged branches. This multi-parent characteristic makes reverting merge commits significantly more complex than reverting regular commits.

Multi-Parent Nature of Merge Commits

Every merge commit contains two or more parent commits, reflecting the essence of branch merging. This relationship is clearly visible through the git log command:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

In this example, commit 8f937c6 is a merge commit with two parent nodes: 8989ee0 and 7c6b236. The former typically represents the main branch (the branch being merged into), while the latter represents the feature branch (the branch being merged).

Core Function of the -m Parameter

The -m option in the git revert command specifies the parent number, which is crucial for reverting merge commits. Since merge commits contain multiple potential revert targets, Git requires explicit instruction about which parent node's state should be restored.

The parent number determination follows these rules:

• -m 1: Restores to the state of the first parent, typically the main branch state before merging
• -m 2: Restores to the state of the second parent, typically the feature branch state before merging

Pre-Revert State Analysis

Before executing the revert operation, it's recommended to analyze specific changes introduced by the merge using the git diff command:

git diff 8989ee0 8f937c6

This command displays all changes from the first parent to the merge commit, helping developers understand the modifications that will be undone. Similarly, the second parent can be compared:

git diff 7c6b236 8f937c6

Complete Revert Operation Workflow

The standard workflow for reverting pushed merge commits includes the following key steps:

Step 1: Identify Target Merge Commit

Use graphical log commands to locate the specific merge commit:

git log --oneline --graph --decorate

This command visually displays commit history, with merge commits shown as branch convergence points for easy identification.

Step 2: Execute Local Revert

After identifying the target commit, execute the revert command:

git revert -m 1 8f937c683929b08379097828c8a04350b9b8e183

This command creates a new commit that restores the repository state to the version of the specified parent node.

Step 3: Handle Potential Conflicts

Revert operations may trigger code conflicts, causing Git to pause execution and prompt manual resolution:

# View conflicting files
git status

# Mark as resolved after manual conflict resolution
git add resolved_file.txt

# Continue revert process
git revert --continue

Step 4: Complete Revert Commit

After conflict resolution, Git automatically creates the revert commit. Developers can verify the revert effect:

git show HEAD

Step 5: Push to Remote Repository

Push the revert commit to the remote branch:

git push origin master

Alternative Approach: Non-Immediate Commit Mode

For scenarios requiring additional modifications, use the --no-commit option:

git revert -m 1 --no-commit 8f937c6
git commit -m "Revert merge commit 8f937c6"
git push origin master

This approach allows for additional code adjustments before final commit.

Method Comparison and Best Practices

git revert and git reset have fundamental differences in handling merge commits:

• git revert: Creates new inverse commits, preserves original history, suitable for pushed commits
• git reset: Directly removes commits, rewrites history, only applicable to local unpushed commits

Team Collaboration Considerations

Reverting pushed merge commits affects all collaborators, therefore requiring:

• Advance notification to team members about revert plans
• Avoiding revert execution during active development periods
• Absolute prohibition of git push --force to rewrite shared history
• Ensuring all members synchronize with the latest code after revert

Conclusion

Reverting Git merge commits requires deep understanding of multi-parent characteristics. The git revert -m command, by specifying parent numbers, clearly defines revert targets while ensuring correct code state restoration and maintaining version history integrity. In practical applications, combining state analysis, conflict handling, and team collaboration best practices enables safe and efficient management of code merging processes.