A squash merge turns a dependency fix PR into one commit on your main branch, which you can undo with a single git revert. A merge commit also reverts cleanly, but you must name the mainline parent. Pick one method for bot PRs and write it down before the first bad day.
Why the merge method matters for fix PRs
A fix PR usually changes a manifest and a lockfile, sometimes a little code. When it breaks something, the person on call wants one question answered fast: what is the smallest thing I can undo? The merge method decides what "the change" looks like in history.
GitHub documents three methods. A default merge adds all commits from the branch to the base branch in a merge commit. Squash and merge combines the pull request's commits into one commit. Rebase and merge adds the commits individually without a merge commit, and GitHub notes that this always creates new commit SHAs.
The three methods compared for bot PRs
| Method | What lands on main | Reverting it |
|---|---|---|
| Squash and merge | One commit | Revert that one commit |
| Merge commit | A merge commit plus the branch commits | Revert the merge commit, naming the mainline parent |
| Rebase and merge | Each commit, no merge commit | Revert each commit, in reverse order |
Git's own documentation explains the merge commit case. Usually you cannot revert a merge because git does not know which side is the mainline, so you pass the parent number with the mainline option. Git also warns that reverting a merge declares you will never want those tree changes, which affects a later re-merge of the same branch.
Bot PRs are often one logical change already, so squash loses little. GitHub does list drawbacks of squashing: you lose when each original change was made and who authored it, and some SHA based commands get harder. For a bot that is rarely a problem, because the PR description, not the individual commits, carries the story.
A simple rule
Use squash and merge for bot PRs that bump one package or one group. Keep the PR title and body in the squashed commit message, because that is what a future reader will see in the log. If your repository mandates merge commits for everything, keep that, and add the revert recipe to your runbook.
Whatever you choose, enforce it in repository settings. GitHub lets you allow only the method you want. If a merge queue is in use, note that the queue controls the merge method instead of the person clicking.
Reverting through the interface
GitHub's revert button creates a new pull request that reverts the merged one, and it requires write permission. The docs add a caveat: you may need to revert individual commits if reverting the PR causes conflicts or if the original was not merged on GitHub. Practise it once on a harmless bump so nobody meets the button for the first time during an incident.
Remember that a revert is itself a change. It should pass the same checks as any other pull request, and your gate should not turn into a second outage by blocking it for the wrong reasons. If your rules cannot tell a revert from a risky change, see should a revert pull request go through the security gate.
Do not forget the lockfile
A revert that restores the manifest but leaves a regenerated lockfile in place is a half revert. Because a squashed fix PR contains both files in one commit, reverting it restores both together. That is one more small argument for squash.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Does squash and merge hide a bad commit inside the fix PR?
It folds the branch's commits into one, so the individual commits are no longer separate on main. For a bot PR that is usually fine, since the review happened on the whole diff. Keep the PR description in the commit message.
Can I revert a merge commit from a fix PR?
Yes. Git requires you to say which parent is the mainline, using the mainline option. Reverting a merge also affects any later attempt to merge the same branch again, so read the git documentation first.
Should bot PRs use a different merge method from human PRs?
Only if you have a reason. One consistent rule is easier to remember at 2 a.m., and consistency matters more than which method you pick.
Sources
- GitHub Docs: About merge methods
- GitHub Docs: Reverting a pull request
- Git documentation: git-revert
Last reviewed: 19 October 2026.
