Stacked Pull Requests Change Review Shape
On July 30, 2026, GitHub announced stacked pull requests in public preview. GitHub describes a stack as an ordered series of pull requests, each representing a focused layer of a larger change. Reviewers can inspect each layer independently, while the stack map shows how that layer relates to the rest of the work.
The preview is rolling out to all repositories and supports github.com, the GitHub CLI through the github/gh-stack extension, GitHub Mobile, and coding agents using the gh-stack skill. Existing reviews, checks, merge requirements, and branch protections continue to apply. Merge queue support is rolling out progressively, according to the announcement.
The Unit of Review Gets Smaller
A large pull request usually asks a reviewer to solve several problems at once: understand the architecture, separate mechanical changes from behavior, evaluate tests, and predict how the pieces interact. A stack does not remove those responsibilities, but it changes their shape. Each pull request can represent one decision with a narrower diff and an explicit dependency on the layer below it.
That is more than a line-count improvement. A good layer can state one invariant: introduce the data structure, migrate one call path, add the user-facing behavior, then remove the old path. Reviewers can challenge each invariant before the next layer lands. The stack map preserves the larger story without forcing every reviewer to reconstruct it from a single mixed diff.
Useful rule: A stack layer should be independently reviewable, not artificially independent. It may depend on lower layers, but its purpose and validation evidence should still be understandable on their own.
Branch Direction Becomes Load-Bearing
GitHub's model starts with a branch and pull request for the first change, then adds branches and pull requests on top. Each pull request targets the layer below it. That target relationship defines what its diff means. If a middle layer is rebased incorrectly or retargeted to the default branch too early, the reviewer may see unrelated lower-layer changes mixed into the diff.
Teams adopting stacks should make parentage visible in naming and automation. The pull request body should name the prior and next layers. Validation should run on every layer, not only the top. Tools should verify that the expected base branch still matches the stack map before a merge or rebase changes history.
Parallel Review Needs Serial Integration
GitHub emphasizes that different layers can be reviewed in parallel. That can reduce waiting time, especially when one reviewer focuses on storage and another on interface behavior. But parallel review does not make integration parallel. The dependency order remains real.
A coordinating owner still needs to reconcile findings across layers. A requested change to a lower-layer interface can invalidate assumptions in every pull request above it. The safe workflow is parallel inspection with a serial integration gate: update the lower layer, propagate the change upward, rerun checks, then merge from a known stack state.
Partial Merge Is a Product Decision
The preview supports merging an entire ready stack or landing lower layers while upper layers remain open and are automatically rebased and retargeted. That flexibility is useful only when lower layers are safe to ship independently. An internal refactor may be fine without the feature above it; a schema change that requires an upper-layer reader may not be.
Before allowing partial merge, each layer should state its deployability. Does it preserve current behavior? Is dormant code acceptable? Can it be rolled back without breaking higher layers? A green check says the layer passes its tests. It does not answer whether the partial product state is intended.
Coding Agents Benefit From Narrow Contracts
GitHub explicitly includes coding agents among the ways to work with stacks. The benefit is strongest when each layer has a contract small enough for both an agent and a reviewer to verify. Instead of asking an agent to implement a broad feature across storage, UI, migration, and documentation, a team can assign one bounded layer with acceptance evidence and an ownership boundary.
The risk is producing a stack mechanically without preserving design coherence. Six small pull requests can still encode one bad architecture. The stack needs an umbrella contract that names the end state, constraints, layer order, and cross-layer tests. Smaller diffs improve review accuracy; they do not replace system-level review.
An Adoption Checklist
- Choose a change with real dependency layers, not unrelated tasks bundled for convenience.
- Write the end-to-end contract before splitting the stack.
- Give each layer one purpose, explicit base, and focused validation evidence.
- Mark whether each layer is safe to merge and deploy independently.
- Propagate lower-layer review changes through every dependent pull request.
- Run an end-to-end check against the complete stack before the coordinated merge.
- Keep branch protections and required reviews enabled; stacking is not a bypass.
Stacked pull requests change the review surface from one large decision into a dependency-ordered sequence. Used carefully, that makes feedback earlier and more precise. The engineering discipline is to preserve both scales at once: narrow evidence for each layer and one accountable view of the complete change.
References
Public-preview behavior and rollout details can change. Verify current CLI, merge queue, and repository support against GitHub's official documentation before standardizing a production workflow.