Bot pull requests get rebased when the base branch moves and the tool wants each branch tested against current code. Every rebase reruns CI. You can cut the churn by rebasing only when there is a conflict, by merging through a queue, or by scheduling updates so they land in one batch.
What triggers a rebase
The documentation of one widely used bot says it rebases an open pull request when it detects a change to that update, such as a new version, a reopened pull request, a changed target branch, or a conflict after a push to the target branch. Another bot's noise guide adds that conflicts in the manifest and, often, the lockfile, are common reasons a branch becomes stale after you merge another pull request.
Lockfiles are the usual culprit. Two update branches that both edit the same lockfile will conflict as soon as one merges.
The setting that controls it
The first bot exposes a rebase setting with several modes. Per its documentation:
| Mode | Behavior |
|---|---|
| auto | The tool picks. It rebases when behind the base branch if it is automerging or the repository requires up to date branches, otherwise only on conflict |
| conflicted | Rebase only when there is a conflict |
| behind-base-branch | Rebase whenever the branch is behind |
| never | Do not rebase |
| automerging | Rebase when behind only for pull requests set to automerge |
The documentation also notes that when the base branch has a merge queue, the automatic mode chooses conflict only, because the queue already tests each pull request against the head of the base branch. The other bot we read about has a simpler switch to disable automatic rebasing, with a caveat that pull requests already open keep their earlier behavior.
How to reduce the churn
- Check whether your repository requires branches to be up to date before merging. That branch protection rule forces a rebase and a fresh CI run after every merge. It is a large multiplier.
- If you can, use a merge queue so tests run against the combined result once, instead of rebasing every open pull request.
- Choose conflict-only rebasing for pull requests you review by hand.
- Reserve rebase on every change for pull requests that automerge, where freshness is the point.
- Lower the number of open update pull requests so fewer branches go stale together. Our post on how many open update pull requests to allow covers that.
- Group related updates, so one lockfile change replaces many.
A caution about stale branches
The noise guide warns that a stale branch may only be rebased when the tool next runs inside its schedule. If you schedule updates for a single weekly window, leave enough time in the week to merge them all, or you will meet the Monday morning pile of conflicted branches.
Fewer rebases is not always better. A branch that never rebases may pass CI against old code and then fail on the base branch after merge. Match the setting to the risk: conflict-only for reviewed changes, always fresh for automerged ones.
Quick check
Why does one merge restart CI on every other bot pull request?
Probably because branches must be up to date with the base branch, so each merge makes the others stale and triggers a rebase.
Is disabling rebases safe?
It saves CI, but branches can fall behind and conflict. Use it for reviewed pull requests, and keep fresh branches for anything that automerges.
Safeguard focuses on what to fix first. It scans manifests and lockfiles into an SBOM, applies policies and gates to pull requests, and uses reachability analysis to show which flagged dependencies your code calls. Fix pull requests are off by default, with every category on Manual. You can run a free scan.
Sources
- Update bot documentation: configuration options, rebase setting
- Update bot documentation: noise reduction
- Code host documentation: update bot options reference
Last reviewed: 19 October 2026.
