Use individual pull requests when a change is risky or you need to revert one fix cleanly, and group when updates are small, related and low risk. GitHub's dependency update bot defaults to one pull request per dependency, and grouping is an opt-in setting to reduce the number of pull requests.
What each approach costs
| Factor | Individual PRs | Grouped PRs |
|---|---|---|
| Review volume | High | Lower |
| Revert one fix | Simple | Harder, may need a split |
| Finding the breaking update | Obvious | Needs bisecting |
| CI cost | One run each | One run for many |
| Merge conflicts | More likely across PRs | Fewer |
GitHub's options reference describes grouping as a way to combine matching dependencies into fewer, targeted pull requests, and says a dependency that matches several rules lands in the first matching group. For security updates, grouped pull requests never span package ecosystems and are not mixed with version updates.
A rule that works
Group by risk, not by convenience:
- Patch updates of the same ecosystem and ownership: group them. They rarely break anything.
- Minor updates: group only within a family, such as packages released together.
- Major updates and anything that needs code changes: keep individual.
- Anything touching auth, crypto or serialisation: keep individual so reviewers focus.
Read how risky a patch, minor or major fix is when deciding the boundaries. Remember that a version number only reflects what the maintainer promised.
Handling a grouped PR that fails
When a grouped pull request fails CI, find the culprit by removing one dependency at a time. If this happens twice a month, your groups are too wide. Narrow them, and record which dependency caused trouble.
Security fixes are a separate case
An urgent fix for a known exploited vulnerability should not wait for a weekly group. Keep an individual path for urgent fixes with a clear owner, and let routine fixes ride in groups.
How to review a grouped pull request
Read the description first. It should list every package, the old and new version, and the type of jump. Then scan the lockfile diff for transitive changes the list did not mention. If a group mixes a patch bump with a package that shows up in your authentication or data path, split it. Reviewers cope well with five small related changes and badly with twenty unrelated ones, so cap group size as well as scope. Revisit the grouping rules after a month using your revert and failure counts.
Where Safeguard fits
Safeguard's autonomous remediation opens fix pull requests with every category on Manual approval by default, so you control what merges. Vulnerability findings come from SBOM and dependency scanning, and you can start with a free scan.
Quick check
Do grouped PRs make auditing harder?
Slightly, because one approval covers several changes. Keep the PR description listing each update and its version jump.
Can I group across languages?
GitHub's docs say grouped security updates do not span package ecosystems, so expect one group per ecosystem.
Sources
Last reviewed: 19 October 2026.
