GitHub stacked pull requests: what native stacking actually changes

GitHub stacked pull requests went from community workaround to native feature in April 2026. A stack, in GitHub’s own definition, is “a series of pull requests in the same repository where each PR targets the branch of the PR below it, forming an ordered chain that ultimately lands on your main branch.” Teams have faked this for years with careful branch targeting and third party tools. Now the platform tracks the chain itself. This piece covers what shipped, what it changes, and how to actually review a stack.

What GitHub stacked pull requests actually are

Each PR in a stack targets the branch of the PR beneath it instead of main. The bottom PR targets main; everything above it targets its neighbor. GitHub’s UI shows a stack map so reviewers can see where a given PR sits in the chain and move between layers. When you merge, per the docs, “the remaining PRs in the stack are automatically rebased so the lowest unmerged PR targets the updated base branch,” which kills the manual retargeting ritual that made hand-rolled stacks miserable. Two details matter more than they look: branch protection rules are enforced against the final target branch, not just the direct base, and CI runs for every PR in the stack as if it were targeting the final branch. The gh stack CLI extension automates creating and restacking, but GitHub is explicit that it is optional; stacks can be managed through the UI or API.

GitHub said the quiet part out loud

The most interesting artifact of the launch is the admission that came with it. As InfoWorld reported, GitHub’s framing was blunt: “Large pull requests are hard to review, slow to merge, and prone to conflicts. Reviewers lose context, feedback quality drops.” That is the platform that hosts most of the world’s code review conceding what reviewers have said for years. The vendor answer used to be “write smaller PRs,” which is correct and useless, because real features do not arrive in 200 line increments. Stacks are the first native acknowledgment that the unit of work and the unit of review are different things, and that the tooling should bridge them.

The new calculus for Graphite and friends

An entire tool category existed to paper over this gap: Graphite, spr, stack-pr, and a dozen scripts named some variant of restack.sh. Their core value was mechanical: keep dependent branches rebased, retarget PRs when a layer merges, give reviewers a map. Native stacks absorb exactly that layer. What remains for third parties is everything above the mechanics: review queues, team analytics, polish, and workflows that span repositories. If you pay for a stacking tool today, the question is which of those you actually use. We keep a broader comparison in our review tooling roundup, but the honest summary is that the free floor just rose, and paid tools now have to justify themselves on the parts GitHub did not build. Expect the survivors to retreat upmarket toward team workflow and analytics; the pure restacking utilities have the most to lose.

How to review a stack without wasting the structure

A stack only helps if reviewers use the layers. The pattern that works:

• Review bottom up. The lowest PR is the foundation everything above it assumes. Approving layer three while layer one is still contested just queues up rework.
• Demand one idea per layer. A stack of three grab-bags is worse than one big PR, because now the mess has ceremony. Each layer should be a single reviewable claim: the refactor, then the new API, then the callers. This is the atomic commit discipline promoted to PR granularity.
• Keep layers inside the size where review still works. The evidence on effective PR size did not change because stacking shipped; stacks are how you honor it on multi-thousand-line features.
• Comment on the layer that owns the problem. If a flaw in layer one surfaces while reading layer four, raise it on layer one so the fix cascades cleanly.

If you review outside github.com, the layers travel with you: Pyor now surfaces the same stack, a navigator in the PR header and a per-layer status panel in the merge box, so you can see where a PR sits, jump between layers, and know which one has to land first while you read. It reads the stack GitHub tracks; it does not create stacks or run a merge queue.

Honest limits

First, maturity: the feature reached public preview for all repositories on 30 July 2026, but GitHub still labels it “subject to change,” and merge queue support was rolling out in the weeks after launch rather than on day one. Second, the cascading rebase automates the mechanical rebases, but conflicts between layers are still yours to resolve; automation moves the work, it does not delete it. Third, and most important: stacking is a discipline before it is a feature. The tooling cannot decide where the seams in your change are. An author who cannot split a feature into coherent layers will produce incoherent stacks, and analysts covering the launch flagged exactly this organizational cost. The teams that get value will be the ones that already think in reviewable units and finally have a platform that does not fight them.