Git Revert -m
You use git revert m to undo a merge commit by picking a parent branch. The parent number tells Git which branch history to keep as the main line. Development teams often run this action when a bad feature branch breaks the shared build. If repo roles are too broad, anyone can push a broken revert to the main branch. Broad write access also lets users bypass code review on critical fixes. How git revert m works on merge commits A normal commit has only one parent in the commit graph. Git know
Git Commit Signing (GPG, SSH): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use git revert m to undo a merge commit by picking a parent branch. The parent number tells Git which branch history to keep as the main line. Development teams often run this action when a bad feature branch breaks the shared build. If repo roles are too broad, anyone can push a broken revert to the main branch. Broad write access also lets users bypass code review on critical fixes.
How git revert m works on merge commits
A normal commit has only one parent in the commit graph. Git knows how to undo it by reversing the exact line changes. A merge commit is different because it joins two or more parent commits together. Git cannot guess which branch is the main line and which is the side branch. You must state the parent number so Git knows what state to restore.
In most workflows, parent one is the target branch that received the merge. Parent two is the feature branch that brought in the new code. When you select parent one, Git keeps the main branch state. It drops all the changes introduced by the merged feature branch. Git then creates a brand new commit that reverses those specific changes. The old commits stay in the log, which protects shared history for the team.
What happens when you re-merge after a revert
Undoing a merge commit removes the code changes, but it keeps the history intact. Git still sees the original feature branch commits as part of the main branch history. If you fix the bug on the same feature branch, a new merge will fail. Git will ignore the old commits because it thinks they are already in the main branch. It will only bring over the brand new commits added after the first merge.
To bring back the full feature work, you have two main paths. You can revert the revert commit itself before merging the new bug fixes. Or you can create a fresh branch and apply the changes as new commits. Teams must check commit graphs before running these steps on production branches.
Git Commit Signing (GPG, SSH): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What branch permissions solve and what they leave open
Source control hosts let teams set up branch rules to guard main lines. These rules require pull requests and review approvals before a merge or revert happens. Role settings decide who can log in and write to a protected branch. This setup stops unreviewed pushes and keeps the commit log clean.
Still, source control roles only check who pushes code to the repo. They do not govern what happens when engineers run commands against live systems during an incident. When a bad merge reaches production, engineers often need live system access to fix state. Static database or server credentials give broad access during these tense rollback moments. Teams still need a way to inspect individual commands and mask sensitive fields like emails or card numbers in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Which parent number should I pick when undoing a merge?
You should pick parent one in almost every standard workflow. Parent one is the branch you were on when you ran the original merge. Picking it tells Git to keep that branch and undo the incoming feature branch.
Why did my changes disappear when I merged the branch a second time?
Git tracks history by commit IDs, not just by file contents. Because the original commits are still in the branch history, Git skips them on the next merge. You must revert the first revert commit to bring those original changes back.
Does reverting a merge commit erase the commit history?
No, reverting never deletes old commits from the repo log. It writes a new commit at the tip of the branch with opposite changes. This makes it safe for shared branches where others have already pulled the code.