On 6 October, GitHub made stacked pull requests generally available. The feature allows engineers to break one substantial change into a sequence of dependent pull requests, review each layer independently and merge all or part of the stack while preserving the dependency order.
This sounds like a workflow convenience. For engineering leaders, it is more consequential. Pull request size is one of the quiet variables shaping delivery speed, review quality and operational risk. Stacks offer a way to reduce batch size without forcing engineers to wait for every intermediate change to reach the main branch. Used well, they can shorten feedback loops and make architectural intent easier to review. Used badly, they can turn one opaque change into five interdependent queues.
The problem is not large pull requests alone
Most teams already know that large pull requests are difficult to review. The reviewer must reconstruct more context, defects hide amongst mechanical changes and feedback arrives late, when rework is expensive. Yet simply telling engineers to submit smaller pull requests often fails. A meaningful feature may depend on a schema change, a service layer, an API and a user interface. Each layer can be reviewable before the whole feature is releasable, but the work is not necessarily safe to merge independently.
GitHub's native stacks formalise the dependency graph. The bottom pull request targets the trunk, and each higher pull request targets the branch below it. GitHub supports stack navigation, partial or complete merging, automatic retargeting and merge queue integration. Branch protection and CODEOWNERS requirements are enforced across the layers, including pull requests that do not directly target the default branch.
Smaller review units change the economics of feedback
The principal advantage is not fewer lines per review. It is earlier, more targeted decisions. A Staff Engineer can review the data model before the product layer is complete. A security specialist can examine an authorisation boundary without parsing the user interface. A frontend engineer can begin against an agreed API layer while infrastructure changes remain under review.
This makes stacks particularly useful for cross-cutting migrations, platform upgrades and features that span several architectural boundaries. The author can separate mechanical preparation from behavioural change, isolate generated files from human-written logic and distinguish an enabling refactor from the feature that depends on it.
The management risk is invisible work in progress
Stacks do not eliminate coordination costs. They relocate them. A five-layer stack may present five tidy review pages while still representing one large item of work. Reporting based on pull request counts can therefore become misleading. Review dashboards may show high throughput even though no customer value has reached production.
Dependencies also create queueing effects. If the bottom layer stalls, everything above it is technically active but operationally blocked. Changes requested near the bottom can cascade upwards, increasing rebase and retest work. Reviewers who inspect only their assigned layer may miss assumptions that cross the entire stack.
Leaders should therefore treat a stack as one delivery unit with several review units. The stack needs a clear owner, an explicit outcome and a visible critical path. Cycle time should be measured from the first layer opening to the usable outcome reaching production, not from the opening and closing of each individual pull request.
Adopt constraints before adopting the tool
A sensible operating policy should answer four questions.
- When is a stack appropriate? Use it when layers have distinct review concerns and an intelligible dependency order. Do not use stacks to compensate for work that has not been decomposed at the product or architecture level.
- How large may a stack become? Set a soft limit, perhaps three to five layers. Beyond that, require a design note or a deliberate checkpoint. Deep stacks magnify coordination cost and make late changes expensive.
- Who reviews the whole? Layer-specific reviewers are valuable, but one accountable engineer must evaluate end-to-end behaviour, rollout and failure modes. Passing every local review does not prove that the assembled system is coherent.
- How is incomplete work kept safe? Use backwards-compatible changes, feature flags and expand-and-contract migrations. A stack is a review mechanism, not a substitute for deployability. The main branch should remain releasable as layers land.
Run a measured trial
Do not announce that all complex work must now use stacks. Select two or three suitable changes, ideally a cross-layer feature, a dependency migration and a refactor with mechanical preparation. Compare them with similar historical work.
Measure total lead time, time awaiting first review, review rounds, escaped defects and the amount of rework caused by changes to lower layers. Ask reviewers whether each layer carried enough context to make a sound decision. Also watch CI consumption: validating every layer against relevant protections can increase pipeline demand even when the human review experience improves.
The decision is not whether stacked pull requests are universally better. It is whether they allow a particular organisation to reduce review batch size without increasing dependency overhead beyond the value gained.
A workflow feature is also an organisational design choice
Engineering tools encode assumptions about how teams coordinate. The traditional pull request assumes that a change can be presented as one reviewable unit. Stacks acknowledge a more realistic pattern: valuable changes often contain ordered decisions that benefit from different expertise and different timing.
GitHub has now made that pattern a first-class workflow. The opportunity is not to produce more pull requests. It is to design smaller, earlier and more accountable decisions while keeping the delivery outcome visible. That requires policy, metrics and review ownership, not merely a new CLI command.
Source note: GitHub announced the general availability of stacked pull requests on 6 October 2026. GitHub's technical documentation describes stack structure, branch protection, CI behaviour, merge options and current platform limitations.
No comments:
Post a Comment