GitHub Stacked Pull Requests Reach General Availability

On October 6, 2026, GitHub made Stacked Pull Requests generally available. Developers can split a large change into smaller dependent pull requests that are reviewed independently.

GitHub reports that repositories using stacks saw 9% more merged code than peers during the preview. This is an observed comparison, not proof that the feature alone causes a 9% productivity gain.

WHAT STACKED PULL REQUESTS DO: A conventional pull request presents changes against a base branch. A stack allows one change to build on another while each dependent change remains a separate review unit. This can support incremental development without presenting the entire feature as one large diff.

A PRACTICAL EXAMPLE: A new interface might require shared data types, API integration and UI components. These can be separated into dependent pull requests so reviewers focus on one concern at a time. The team must still understand and maintain the merge order.

REVIEW TRADE-OFFS: Smaller diffs can help reviewers concentrate on a specific design decision or defect. Excessively granular stacks, however, can increase notifications and dependency management. The goal is a coherent review unit, not the maximum number of pull requests.

REBASING AND APPROVALS: Changes to an earlier pull request can require updates to later branches. GitHub highlights improvements involving approval preservation, signed replacement commits and merge queues. Teams should check these behaviors alongside their own branch protection policies.

INTERPRETING THE NINE PERCENT FIGURE: The reported comparison describes repositories observed during the preview. Differences in team size, workflow and project complexity may affect the result. It does not establish that adopting stacks will cause a nine percent increase in merged code for every team.

WHEN TO ADOPT: Stacks are worth testing when a large feature can be divided into coherent, dependent changes. Start with a limited project, define ownership and merge order, and measure review wait time, rework and delivery outcomes.

TECHNICAL CONTEXT: The announced approach needs to be understood in its specific technical and operational context. A useful evaluation begins by identifying the exact task, the information available to the system and the expected outcome.

IMPLEMENTATION CONSIDERATIONS: The practical value depends on how the system is integrated with existing processes and controls. Teams should identify which actions are permitted, how failures are detected and who can review consequential results.

EVALUATION AND LIMITS: The stated capabilities and figures should be evaluated under their reported conditions. Independent tests and representative real-world tasks help establish whether the approach is suitable beyond a demonstration.

WHAT TO WATCH: The long-term value depends on integration with existing work, cost, reliability and the ability to verify results. Organizations should track real deployments and repeat evaluations as products change, rather than rely solely on initial demonstrations.

The general availability release improves approval preservation during rebases, signed replacement commits and merge-queue handling for stacks.

The approach can make reviews more focused, but teams still need to manage dependencies carefully. The feature is available across github.com plans, with Enterprise Server support planned for a future release.