GitHub stacked PRs GA: a small diff is not a deployable unit
Splitting a large change into three PRs makes each review screen shorter. If an upper PR depends on changes below it, however, a shorter screen does not make that PR independently deployable.
What shipped on October 6
GitHub announced general availability of stacked pull requests on October 6, 2026. The workflow lets teams review focused PRs separately and merge them together, and is available on all github.com plans.
The announcement says a stack enters the merge queue as one merge group. With the merge commit method, GitHub instead creates a merge commit per PR. Do not assume the tested group and the commit-history unit are identical.
Write down the review boundary
Suppose A adds a shared function, B calls it from an API, and C adds a UI. Describe each change and its dependency PRs, and identify the base reviewers should compare against. This is a suggested workflow, not an automatic product guarantee.
Reading B alone could miss an authorization check omitted in A. Separate review of each diff's logic from validation of A+B+C as a whole, and name the person responsible for the final combination.
Read approvals after the base moves
GitHub says rebasing an otherwise unchanged stack after its base moves now preserves approvals, including in repositories that dismiss stale approvals. Treat an approval badge and evidence of the current integrated result as separate signals.
A small team can record commit SHAs before and after rebase and the merge group actually tested. Check whether tests ran again and which combination their logs cover before merging. A copied green check is insufficient release evidence.
Separate merging from deployment
When the shared function and API must ship together, retain that dependency in the deployment plan. Having one commit per PR does not make arbitrary single-commit rollback safe: remaining callers may break. Review the rollback combination in advance.
Unrelated bug fixes need not become a stack. Stacks help changes that require ordering; grouping independent work can make everyone wait for one delayed verification. That is an operational tradeoff for the team to assess.
Distinguish GA from account availability
GitHub says auto-merge will roll out over the next few weeks. Do not document the same automatic merge button for every account today solely because the feature headline says GA. Check the repository's actual controls.
The official release describes navigation and automation improvements informed by preview feedback. That signals interest, not a productivity guarantee for your team. Measure your own review waiting time and integration failures instead.
Pilot one small stack
For the first week, choose two PRs with a clear dependency, such as a function and its caller. State the base, dependency and verification commands in each PR; agree on integration ownership and rollback scope, then merge once.
Compare shorter review time with any increase in integration failures. If maintaining the stack costs more, return to ordinary PRs. Reduced confusion in review and deployment is a better adoption criterion than the number of diffs.
Official sources
Announcement: October 6; checked for this article on October 8, 2026. Verify repository rules and currently available controls before adopting the workflow.