Auto-rebase
PR branches are kept current with the target branch automatically, so nobody runs git rebase main by hand every time another PR lands.
- CD pipeline includes at least one gate (tests pass, security scan, approval)
- Merge queue is implemented (GitHub merge queue, Mergify, or equivalent)
- Auto-rebase is enabled for PRs targeting main branch
- Merge conflicts are detected and flagged before review is requested
- Deploy frequency is at least daily
- Merge queue configuration in repository settings or CI
- Auto-rebase configuration (branch protection rules, bot configuration)
- CD pipeline definition showing gate conditions
- Delivery L1 (CI/CD Pipeline) - CI pipeline must exist for merge queue to function
What It Is
Auto-rebase is the practice of automatically keeping pull request branches up to date with the target branch without requiring the developer to manually run git rebase main or git merge main on their branch. When main advances - because another PR merged - any open PRs that are behind main are automatically rebased onto the new tip. The developer's branch stays current without any manual intervention.
The technical mechanism varies by implementation. GitHub offers an "Update branch" button (and "Always suggest updating pull request branches" setting) that lets developers rebase with a click. Mergify's queue action and update_branch: true configuration go further, automatically rebasing PRs as soon as they fall behind main. GitHub's merge queue also handles this internally: when a PR enters the queue, it's rebased onto the current queue head automatically.
At L2, auto-rebase is typically implemented at the PR level: when a PR is behind main by more than N commits, a bot rebases it automatically. This prevents the common failure mode where a PR passes CI, gets approved, sits for 24 hours while main advances, and then fails CI when merged because the branch is stale. Without auto-rebase, developers must manually keep their branches current, which is pure overhead with no engineering value.
At higher AI adoption levels, auto-rebase becomes structurally necessary. When agents produce 10-20 PRs per day and each PR might sit in review for hours, the branch drift problem is endemic without automation. An agent-produced PR that was correct when submitted might be incorrect by the time it's reviewed if main has advanced significantly. Auto-rebase ensures the review always reflects the current state.
Why It Matters
- Eliminates "stale branch" failures - a PR that passes CI when opened but fails when merged because main advanced is a source of developer frustration and wasted CI time; auto-rebase makes this impossible
- Reduces review-to-merge latency - developers don't need to manually rebase before merge, which removes a step that typically requires context-switching back to a PR they'd moved on from
- Required for high-throughput merge queues - merge queues that process 50+ PRs/day need each PR to be current before entering the queue; auto-rebase provides this guarantee automatically
- Keeps agent-produced PRs valid - AI-generated PRs can become invalid if main advances and conflicts with the agent's changes; auto-rebase surfaces these conflicts early (when there's time to fix them) rather than at merge time
- Reduces cognitive overhead for developers - "is my branch up to date?" is a question developers shouldn't have to think about; automation removes it from their mental checklist
Getting Started
- Enable GitHub's "Always suggest updating pull request branches" setting - in repository Settings > General, enable this option. It makes GitHub prompt developers to update their branch when it's behind main, and enables the one-click "Update branch" button on PRs.
- Configure branch protection to require branches to be up to date before merging - in branch protection rules, enable "Require branches to be up to date before merging." This prevents merging stale PRs and forces the rebase, though it's still manual until you add automation.
- Add a Mergify configuration for automatic rebase - create a
.mergify.ymlfile with a rule that automatically updates branches when they fall behind:update_bot_squash: falseandqueue_ruleswithupdate_method: rebase. This automates what the GitHub setting makes manual. - Alternatively, use a GitHub Action for auto-rebase - the
peter-evans/rebaseaction triggers on PR updates and automatically rebases the branch when main advances. Configure it to run onpushto main to keep all open PRs current. - Handle rebase conflicts - auto-rebase fails when there's a conflict that requires human judgment. Configure your automation to add a label (
needs-rebase,conflict) and notify the PR author when auto-rebase fails. A failed auto-rebase that's silently ignored is worse than no auto-rebase. - Monitor rebase failure rate - if 20%+ of auto-rebases fail due to conflicts, it indicates PRs are too large or too long-lived. High conflict rates are a signal to improve PR discipline (smaller changes, faster review cycles) not just to improve the rebase automation.
Auto-rebase with --rebase rewrites commit history, which can be disorienting for developers who are used to merge commits keeping a record of when branches diverged. Before enabling auto-rebase, agree on a team standard: rebase (clean linear history) versus merge (preserves branch structure). Most AI-assisted teams prefer rebase for clean history, but make the decision explicitly rather than having the bot impose it.
Common Pitfalls
Auto-rebasing everything including PRs in active review. If a developer is in the middle of reviewing a PR and the branch gets auto-rebased, they lose their place in the diff. The rebased PR looks like it changed everything (because the base changed) even if the actual content is the same. Configure auto-rebase to apply only when PRs are not in active review, or only when they're behind by more than N commits.
Not handling rebase conflicts gracefully. When auto-rebase encounters a merge conflict, it either silently fails or creates a confusing CI failure. Neither is acceptable. Auto-rebase failures must be surfaced clearly: label the PR, notify the author, and explain what happened. "Auto-rebase failed due to conflict in src/api.ts - please resolve manually" is actionable. "CI failed" is not.
Using auto-rebase without a merge queue. Auto-rebase keeps branches current, but if two rebased PRs merge simultaneously without a queue, you still get race conditions. Auto-rebase and merge queues are complementary, not alternatives. Use both: auto-rebase ensures PRs stay current while in review; the merge queue ensures ordered, conflict-free integration.
Rebase loops on high-churn main branches. If main receives many commits per hour and auto-rebase triggers on every push to main, a PR might be continuously rebasing rather than stabilizing. Configure a debounce: only auto-rebase if the branch is more than N commits behind, not on every individual commit to main.
Force-pushing rebased branches breaks CI history. Rebase rewrites commit history and requires a force-push to the PR branch. If CI is configured to track specific commit SHAs, a force-push invalidates previous CI results and triggers a full re-run. This is acceptable overhead for safety, but it means your CI must handle rebased PRs gracefully rather than attempting to cache results across force-pushes.
How Different Roles See It
Bob's team has a recurring pattern: a PR gets approved, but by the time the developer gets around to merging it (after picking up another task while waiting for review), main has advanced and the CI check fails. The developer has to rebase, CI runs again, and the PR might need another review cycle if the rebase introduced anything unusual. This adds 2-4 hours to PR cycle time on average.
What Bob should do: Bob should authorize the team to implement auto-rebase as part of the same sprint as merge queues. The two features are closely related and the implementation cost for auto-rebase is low - it's a configuration change to Mergify or a GitHub Actions workflow, not new infrastructure. Bob should frame it as "we're paying a 2-4 hour tax on every PR merge that sits for more than a few hours; this is the fix." He should also instruct the team to measure "time from approval to merge" before and after, targeting a 50%+ reduction.
Sarah's developer experience data shows "rebase overhead" as a common complaint in retros. Developers describe it as "I had a PR ready to go but had to spend 30 minutes rebasing and resolving conflicts because main moved while I was in a different context." This is invisible in standard metrics but highly visible in developer frustration.
What Sarah should do: Sarah should add "time from approval to merge" to her metrics dashboard alongside "time to first review." The gap between approval and merge is often entirely explained by rebase overhead - the developer approved the PR, moved on to something else, and then had to context-switch back to rebase before merging. Auto-rebase, combined with auto-merge policies (coming at L4), eliminates this gap entirely. Sarah should present this as "here's how we remove the gap between 'reviewed' and 'in production'" - a developer experience win that also directly improves delivery velocity.
Victor runs 3-5 parallel agent tasks and each produces a PR. By the time PR #1 is reviewed and merged, the branches for PRs #2-5 are stale. Victor manually rebases them but this is 15-20 minutes of overhead per session that adds no value. He's already mentally moved on from those tasks and rebase is pure friction.
What Victor should do: Victor should implement Mergify auto-rebase for all repositories where he runs parallel agents. The configuration is straightforward: a queue action with update_method: rebase in .mergify.yml. For his workflow specifically, Victor should also evaluate whether he wants automatic rebase on all open PRs or only on PRs that have been approved and are waiting for merge. Rebasing everything continuously is wasteful; rebasing approved PRs so they're ready to merge immediately after queue entry is the right trigger. Victor should document this configuration as the standard for parallel agent workflows and advocate for it as team-wide policy.
Further Reading
From the Field
Recent releases, projects, and discussions relevant to this maturity level.
Where does your team actually sit on this?
This guide describes one level of one area. Run the assessment to place your team across all 16 areas, see which gates you have passed, and get a report you can take to your stakeholders.
Merge & Deploy