Revert a merged fix pull request by creating a new change that undoes it, then merge that change through your normal checks. Do not rewrite shared history. On GitHub, use the Revert button on the merged pull request. From the command line, use git revert with the mainline flag for merge commits.
Why revert instead of rewrite
Git's own documentation says git revert records new commits that reverse earlier ones. It does not remove or rewrite the originals, which is why it is safe on shared branches. Resetting and force pushing a protected branch breaks everyone else's clones and usually breaks your own rules.
Steps on GitHub
- Open the merged pull request.
- Click Revert near the bottom of the page. You need write permission.
- GitHub opens a new pull request that undoes the original merge commit.
- Let your required checks run on it, get the review your rules demand, and merge.
The change takes effect only when the revert pull request merges. If the revert conflicts, or the original was not merged through GitHub, revert individual commits with Git instead.
Steps on the command line
git revert -m 1 <merge-commit>
A merge commit has more than one parent, so Git cannot know which side is the mainline. Without the mainline flag the command fails. Parent numbers start at 1, and 1 is usually the branch you merged into. For a squash merge, which creates a single ordinary commit, you can revert that commit directly without the flag.
Use the no commit flag if you want to inspect or combine reverts before committing. Git also recommends rewriting the default message to say why you reverted.
The catch with reverting merges
Git's documentation warns that reverting a merge declares you will never want the tree changes it brought in. If you later merge the branch again after fixing it, those original changes will not come back automatically. The standard remedy is to revert the revert, or to open a fresh branch with the corrected change.
What to record
A revert is also evidence. Capture:
- The fix pull request, the revert pull request, and the incident or ticket that triggered it.
- The reason: failed test, runtime error, behavior change, unexpected dependency.
- Who decided, and when.
- Whether the vulnerability the fix addressed is open again. It is, so re-triage it.
That last item is often forgotten. A reverted security fix reopens the finding. Mark it, set a new owner and date, and consider a mitigation such as a configuration change while a better fix is prepared.
Prepare before you need it
- Rehearse one revert in a staging repository.
- Make sure the person on call has write permission.
- Decide in advance whether a revert needs the same review as a normal change. Many teams allow a single approver for reverts to move quickly, with a follow-up review.
- Track revert rate for fix pull requests as a quality signal. See metrics for fix PR quality.
Safeguard offers autonomous remediation with fix PRs, off by default with every category on Manual. A tested revert path is worth having ready before you change that.
Quick check
Can I just force push the branch back to the old commit?
You can on an unprotected branch, but you should not on a shared one. It rewrites history and conflicts with branch protections. Use a revert.
Does reverting a fix close the vulnerability finding?
No. The finding is open again after a revert, so it needs a new owner, a date, and possibly a temporary mitigation.
Sources
Last reviewed: 19 October 2026.
