GitHub made stacked pull requests generally available, allowing related small PRs to be reviewed separately and merged together. The announcement describes changes to rebasing, retained approvals, signatures, and merge-queue behavior. GitHub official announcement
Smaller reviews still have dependencies: an upper PR may require a lower one to function. State the base relationship and the tests the complete stack must pass.
On this page
Smaller changes can still depend on a shared base
A pull request is a unit for reviewing and merging code. Splitting a feature can make each change easier to explain, but later changes may still depend on earlier code. A stack makes that relationship visible during review. Producing smaller diffs and producing independently deployable changes are different design tasks; one does not automatically imply the other.
For example, a stack might introduce a shared helper, update an API to use it, and connect a new interface. Reviewers can inspect each layer separately, but the API change must be tested with the helper present. Describe both the purpose of each PR and the lower changes it assumes so reviewers understand the execution context as well as the local diff.
Approval and integration testing have different meanings
When the base branch changes, branches above it may need rebasing. Retaining approval for unchanged code can reduce repetitive review, but it does not replace testing the combined result against the new base. Distinguish the approval history from the commit combination validated by CI. A familiar diff can behave differently when its surrounding dependencies change.
Review signed-commit and merge-queue behavior against repository rules. If the stack enters the queue as one merge group, understand readiness for the entire stack alongside ownership of each PR. Separate behavior described in the release from features rolling out gradually, such as stack auto-merge, before making them a required part of the team’s workflow.
Database changes expose the difference between review and deployment
Consider a stack adding a schema field, updating the application to use it, and removing the old field. Review order does not establish that all three can safely deploy at once. Old and new application versions may coexist during a rollout. Recovery also depends on whether changed data remains compatible with the earlier application, not simply on whether a commit can be reverted.
Begin with one modest feature and evaluate per-PR CI, combined stack testing, partial merging, and recovery. Compare review waiting time and repeated review using the team’s own records. Results reported for other repositories are not promises for your team. Assess the feature as a way to make dependencies clearer and then refine the process using observed outcomes.
Before adopting stacked review
- Explain the responsibility and dependencies of each PR.
- Test branch rules, commit signatures, and merge queues with a stack.
- Exercise partial merges and rollback using a small change.
General availability does not guarantee faster delivery for every team. Check rollout of detailed capabilities such as auto-merge and measure actual review delays.
Announcement reference date: 2026-10-06 · Checked: October 24, 2026
.jpg){kind=link}