When a grouped fix PR fails, you need to find which package in the group is responsible. Split the group in half, test each half, and keep halving. If the updates are separate commits, git bisect run does this search for you using any command that exits zero on success.
The problem with groups
Grouping saves review time, but a group fails as a unit. Ten bumps in one PR, one red test. Reading ten changelogs is slow. The faster move is a binary search, the same idea git uses to find a faulty commit.
Manual halving
This works with any tool, any ecosystem.
- Check out the group's branch and list the packages that changed, from the manifest diff.
- Revert the second half of the packages to their old versions in a scratch branch.
- Run the failing test. If it passes, the culprit is in the half you reverted. If it fails, it is in the half you kept.
- Repeat on the guilty half until one package remains.
With ten packages that takes at most four rounds, because each round halves the candidates. Lockfile changes make step 2 fiddly, so revert both the manifest entry and let the package manager rewrite the lockfile, rather than editing the lockfile by hand.
Using git bisect
If your tool commits each update separately, git can do the search. Git's documentation describes bisect as a binary search that finds which commit introduced a problem. You give it a known bad commit and a known good one, and it checks out commits in between.
git bisect start
git bisect bad
git bisect good main
git bisect run npm test
The command given to run should exit with code 0 when the current code is good and with a code between 1 and 127, except 125, when it is bad. Any other exit code aborts the bisect. Replace the test command with whatever fails in CI. When it finishes, run git bisect reset to return to your branch.
When the cause is an interaction
Sometimes no single package is guilty. Two updates are fine alone and fail together, for example a library and a plugin that expects the old library. If halving ends with a pair, test each alone and then together. The right fix may be to move both in one step, or to hold one back with a recorded reason.
After you find it
Pull the guilty package out of the group so the rest can merge. Most update tools let you add a rule that excludes one package from a group, or you can close the group PR and let the tool open a smaller one. Then file the package on its own track: read its release notes, decide whether to adapt your code, and give it an owner and a date. For help judging risk before you bump, see upgrade impact analysis: predicting breaking changes before you patch.
Keep a note of which package broke the group. If the same package breaks groups often, give it its own PR from now on. Groups should hold things that behave alike, and an exception that keeps surprising you has earned its own lane. See how to group dependency updates without hiding risk.
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
Do I need separate commits to use git bisect?
Bisect searches commits, so each update needs its own commit. If everything is in one commit, use manual halving instead.
What if the test only fails in CI?
Reproduce it locally with the same command and environment first. A bisect run is only as trustworthy as the command you give it.
Sources
- Git documentation: git-bisect
- GitHub Docs: Optimizing the creation of pull requests for Dependabot version updates
Last reviewed: 19 October 2026.
