How do grouped updates in GitHub's dependabot.yml reduce pull request volume?

## The problem grouping solves A repository with a broad dependency tree and a weekly schedule can produce dozens of individual bump pull requests. Each one costs a CI run, a review click, and a merge. Worse, they interact: merging one rebases the rest, which re-runs their checks, which produces more notifications. Teams respond by ignoring the bot, which is the failure mode the feature exists to prevent. ## How groups are declared `groups:` sits inside a single `updates:` entry, so grouping is per ecosystem and per directory. Each entry is a group name mapped to selection criteria: - `patterns` — a list of globs matched against package names, e.g. `@aws-sdk/*` or `org.springframework.*`. `*` alone matches everything in the ecosystem. - `exclude-patterns` — carves specific packages back out of a group so they keep getting their own pull request. - `dependency-type` — `development` or `production`, useful when your risk appetite differs between test tooling and runtime libraries. - `update-types` — `major`, `minor`, `patch`. This is the most valuable filter: group the boring bumps, isolate the risky ones. - `applies-to` — `version-updates` (the default) or `security-updates`, so you can decide separately whether advisory-driven fixes are collapsed. Groups are evaluated in order; a dependency lands in the first group it matches, so a catch-all group belongs last. ## What actually happens on a run Dependabot performs its normal resolution for the ecosystem, then partitions the set of updates it decided to make. Each non-empty group produces one branch and one pull request whose body lists every member with its old and new version and links to each changelog. Ungrouped updates behave exactly as before. On the next run, if the group's contents change — a member gets a newer version, or a new package matches — Dependabot updates the existing branch rather than opening a second one. Because the group is one pull request, `open-pull-requests-limit` sees it as one. A repository that was permanently pinned at its limit of five open PRs, never reaching the sixth dependency, starts making progress. ## The tradeoff you must state Grouping trades isolation for throughput. Benefits: fewer CI runs, one review, one merge, and a much better signal-to-noise ratio in notifications. Costs: - **All-or-nothing merging.** One incompatible member makes the whole PR red. You then have to work out which one, and either exclude it via `exclude-patterns` or split the group. - **Harder attribution.** If a grouped merge causes a regression, you have a bigger surface to bisect than a single-package PR would have given you. - **Review depth erodes.** A twenty-package PR gets less scrutiny per package than twenty PRs would — which is fine for patch bumps in dev tooling and not fine for a runtime framework major. The usual shape of a good configuration is therefore: a `patch`/`minor` group for production dependencies, a broad group for development-scoped dependencies, explicit exclusions for the two or three libraries that always break, and no grouping at all for majors. ## Interaction with security updates By default, security PRs are not grouped, which is usually what you want: an advisory-driven bump should be independently mergeable and fast. Where a repository receives a steady stream of low-severity advisories in dev tooling, `applies-to: security-updates` on a narrow group is defensible — but grouping a critical runtime fix behind nine unrelated bumps is how a fix sits unmerged for a week. ## Operating a grouped PR When a grouped pull request goes stale or you have changed the group definition, the comment commands still work: `@dependabot rebase` refreshes it against the base branch, and `@dependabot recreate` throws the branch away and rebuilds it from scratch, which is what you want after editing `groups:`. If you need to drop one member, add it to `exclude-patterns` and recreate rather than hand-editing the branch — Dependabot owns that branch and will overwrite manual commits on the next run. ## When grouping is not the answer If the noise comes from a daily schedule on a repository nobody actively maintains, the fix is cadence and ownership, not grouping. If it comes from an ecosystem that publishes constantly, `allow` with `dependency-type: direct` narrows the surface far more than any grouping will. Grouping is a presentation-layer control; it does not reduce the amount of change flowing in, only the number of doors it comes through.