GitHub stacked pull requests are now generally available
Stacks let you break a large change into smaller PRs that review and merge together. GitHub says adopters merge 9% more code and top repos cut time-to-merge by 5%.
GitHub’s stacked pull requests left beta on 6 October. A stack lets you split a large change into a sequence of smaller, dependent pull requests that reviewers can go through one at a time and that merge together once approved, rather than forcing a single sprawling diff or a chain of manually-rebased branches.
GA brings the parts that made stacks fragile in beta: approvals now survive a rebase if the underlying stack code hasn’t changed, rebased commits keep their original signatures and authorship, and a deleted base branch auto-retargets the stack instead of orphaning it. Stack context now sits in the persistent PR header, with Shift+J/K to move between entries, and the gh stack CLI extension works with git worktrees. GitHub says repositories that adopt stacks merge 9% more code than peers, and that among its top 1% of repos, which have largely switched to stacks, time-to-merge is down 5%. Auto-merge for stacks is rolling out over the following weeks.
Why it matters: if your team has been avoiding large refactors because review drags once a diff passes a few hundred lines, stacking is now a first-class, GA feature rather than a beta you’d hesitate to build a workflow around. It’s available on every github.com plan today, with GitHub Enterprise Server support coming in an upcoming release.