On October 6, 2026, GitHub announced that stacked pull requests are now generally available, letting teams break a large change into smaller PRs that can be reviewed independently and merged together. The feature had been in public preview since July 30, 2026; it is now available on every github.com plan, with a GitHub Enterprise Server release announced but undated.
What the preview period showed
During the preview, GitHub reports that repositories using stacks merged 9% more code than comparable repos, with a 5% improvement in time-to-merge. More than two-thirds of the top 1% most active GitHub repositories already use the mechanism, a sign of adoption among high-volume contributing teams.
Merging and rebasing: the real change
The shift to general availability is mostly about the merge mechanics. The rebase stack command now preserves approvals already given on unchanged code, even in repositories configured to dismiss stale approvals on every new commit. Rebased commits stay signed when branch rules require it or when the original commits were signed, and original authorship is preserved.
A stack enters and moves through the merge queue as a single merge group: with the merge commit method, GitHub creates one merge commit per PR. If a stack’s base branch is deleted, the stack is automatically retargeted instead of closing its bottom PR, which supports stacks branching off other stacks.
| Aspect | Before (preview) | At general availability |
|---|---|---|
| Rebasing | Invalidated approvals | Preserves approvals on unchanged code |
| Merging | PR by PR | Single merge group via the merge queue |
| Deleted base branch | Bottom PR closed | Stack automatically retargeted |
| Auto-merge | Not available | Rolling out over several weeks |
Navigation and automation
Stack information now shows up in the PR page’s persistent header and in the pull requests list view. Shift+J and Shift+K move between PRs in the same stack, and the timeline shows when a PR joins or leaves a stack. The pull_request webhook now exposes a stacked action when a PR joins a stack, for example to adjust the GitHub Actions caching strategy depending on whether a PR belongs to a stack or not.
The gh stack CLI extension gains support for Git worktrees, plus faster initialization, checkout, and navigation. A developer juggling several stacks at once no longer needs multiple clones to do it.
gh stack create feature/refonte-auth
gh stack push
gh stack sync # rebase + mise à jour de la stack entière
gh stack ls # liste les PR de la stack courante
More than two-thirds of the top 1% most active GitHub repositories already use stacked pull requests.
Auto-merge for stacks is rolling out over several weeks: a team that doesn’t see it in its repository settings yet has nothing to configure on its end, it’s a GitHub-side rollout.
For teams already stacking PRs by hand
Teams that already stacked PRs manually, through naming conventions or third-party tools, can migrate without changing how they work: the same CLI habits remain valid, GitHub adds the merge mechanics on top. The main benefit stays review quality: a 2,000-line PR turns into five 400-line PRs, each with its own review context.
Key takeaways
Stacked pull requests leave preview with sturdier merge mechanics: approvals preserved through rebasing, grouped merges via the merge queue, and a faster CLI extension. The feature is available on every github.com plan starting today, with no action required for repositories that don’t use it yet.
Stacks solve a real code review problem, but they demand a discipline many teams don’t have yet: if a PR in the middle of a stack changes significantly after review, everything downstream needs rebasing, and that’s where GitHub’s automatic rebasing really earns its keep. Worth testing before making it a team convention. — Simon Janvier
Further reading: the official announcement on the GitHub changelog.
