GitHub Stacked Pull Requests: What Shipped and What to Measure

On 30 July 2026, GitHub put stacked pull requests into public preview. Instead of submitting one large pull request, developers can split a change into a chain of smaller, dependent PRs and review each layer independently.

That gives teams a workflow for keeping changes small. But it does not tell them whether their large PRs actually got smaller.

To see that, start with two numbers: median PR size and P90.

What GitHub shipped

A stack is a chain of two or more pull requests in the same repository. The bottom PR targets the trunk, usually main. Each PR above it targets the branch below.

A reviewer opening one layer sees only that layer’s diff—not the entire feature. Different reviewers can work on different layers in parallel, and developers can continue building on work that has not merged yet.

Stacks merge from the bottom up. You can merge one layer, part of the stack, or the whole chain. GitHub then rebases and retargets the remaining open PRs automatically.

The local workflow is provided through the github/gh-stack CLI extension:

gh stack init
gh stack add api-endpoints
gh stack submit

Stacks also appear on github.com and GitHub Mobile. GitHub’s documentation recommends placing foundational work—such as shared types or database changes—in lower layers, with dependent work above it.

The key constraint is simple: if code in one layer depends on another, that dependency must be in the same layer or a lower one.

Why teams care

Small PRs are easier to finish reviewing. A focused diff demands less context, is less likely to be skimmed, and is less likely to become stale while waiting for attention.

Stacking also lets the next change begin before the previous one has merged. Instead of waiting for a foundational PR to land, a developer can build the next layer on top of it while keeping the review boundaries separate.

TED CTO Andy Merryman described the pressure behind the feature in GitHub’s announcement:

“AI has made TED's developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling.”

GitHub’s launch video shows the everyday version of the problem: one planned change expands into a nearby bug fix, a UI cleanup, and another small improvement. The result is a PR nobody wants to read. A stack gives each concern its own reviewable layer without forcing the developer to wait between them.

Aren’t commits already a stack?

That was one of the main arguments in the r/programming discussion, which attracted hundreds of comments.

Commits already divide implementation history into steps. But a single PR still presents one combined review request. Stacked PRs divide the review workflow itself: each layer has its own diff, discussion, approvals, CI status, and merge decision.

That matters when different parts of a change need different reviewers. As one commenter put it:

“It's almost always easier to review 10 small PRs than one massive PR. Oftentimes people reviewing PRs 1 and 2 aren't necessarily the same ones that need to review PRs 3 and 4.”

The trade-off is additional process. A stack creates more PRs to navigate, approve, and merge. If reviewers already work commit by commit inside well-structured PRs, stacking may add overhead without solving a meaningful problem.

If reviewers usually see one thousand-line diff and one review request, however, a stack gives them smaller units they can actually finish.

What is still rough in the preview

This is a public preview, and GitHub says the feature is subject to change. Its current documentation lists several constraints teams should test before rolling it out:

• Every branch in a stack must be in the same repository. Cross-fork stacks are not supported.
• GitHub Desktop does not support stacked pull requests.
• Branch protection rules, including CODEOWNER approvals, are enforced on every layer.
• CI checks that normally run for PRs targeting the trunk run on every PR in the stack.
• API-based merges must use GitHub’s asynchronous merge endpoint for stacks.

At launch, merge-queue support was still rolling out progressively. GitHub’s current documentation now describes stacks as merge-queue aware, but teams should still test their exact branch rules, approval requirements, CI setup, and merge method.

The Hacker News discussion concentrated heavily on early preview behavior. One commenter described friction between squash merging and rules that require renewed approval after changes to a layer. GitHub’s documentation lists merge commits, squash merges, and rebase merges as supported, but support on paper does not guarantee that every organization’s rules will produce a smooth workflow.

Test the complete path with a small group before asking the whole organization to stack.

How to tell whether your team needs stacked PRs

Stacking is a workflow for keeping dependent changes reviewable. If your typical PR is already small and large PRs are rare, it may add process without addressing a real problem.

If a regular share of PRs is very large, stacking may help—but first you need to see the distribution.

Start with two numbers:

• Median PR size describes the typical PR. Half of measured PRs are smaller and half are larger.
• P90 PR size exposes the large-PR tail. Nine out of ten measured PRs are this size or smaller; the remaining 10% are larger.

Median alone can hide the changes reviewers struggle with. A team may have hundreds of tiny fixes and still produce a steady stream of enormous feature PRs.

GitQuick measures PR size as additions plus deletions. Those numbers trigger the PR Size / Complexity Risk signal, a named check on review health, when the median exceeds 400 lines or P90 exceeds 1,000 lines. When both are high, oversized PRs are not a few exceptions. They are part of the normal workflow.

Lines changed are an imperfect proxy for review difficulty. Generated files, dependency updates, formatting changes, and mechanical migrations can produce large diffs without equivalent cognitive complexity. The tail is therefore a signal to investigate, not a verdict on the author or the code.

What the large-PR tail looks like in practice

The following figures come from public organizations in the GitQuick showcase. They use one-month windows ending between 9 and 15 August 2026.

The typical PR is not the problem. Every organization in this table is well below 400 lines at the median. Looking only at the typical PR would suggest that PR size is healthy across the board.

The tail tells a different story. In five of the nine organizations—Google Cloud, AWS, OpenAI, Uber, and Vercel—at least 10% of measured PRs are roughly 1,000 lines or larger.

AWS shows the clearest split. Its median PR is just 56 lines, while its P90 is 1,629. In other words, roughly one in ten measured AWS PRs is larger than 1,629 lines.

That does not mean every large AWS PR should become a stack. Some may contain generated or mechanical changes. But the median alone would never tell you that this tail exists, and that tail is where teams should investigate whether changes can be divided into smaller, dependent reviews.

Vercel shows why adoption and measurement are different

GitHub’s launch announcement names Vercel as an early user. Tim Neutkens, Next.js lead at Vercel, said stacked PRs helped the team introduce smaller individual changes while shipping larger features.

In the GitQuick showcase window, Vercel’s median PR is 160 lines—a healthy typical size. Its P90 is 1,357 lines.

That does not contradict Vercel’s experience. A one-month organization-level distribution includes different repositories, contributors, change types, and workflows. It also does not tell us which PRs were part of stacks.

It does show why enabling a workflow and measuring its outcome are separate things. Native stacking gives authors the mechanism to split a large feature. The size distribution tells teams whether reviewers are actually receiving smaller diffs.

Measure the outcome, not the adoption

Median and P90 are enough to expose a size problem. They are not enough to explain every large PR or prove that stacking caused an improvement.

Use them as the beginning of the investigation:

• If median and P90 are both healthy, stacked PRs may add process without solving an important problem.
• If the median is healthy but P90 is high, inspect the large-PR tail. When those PRs are dependent feature work that can be divided logically, stacking is a strong fit.
• If both median and P90 are high, oversized PRs are a broader workflow pattern rather than a handful of exceptions.

After introducing stacked PRs, measure again. Look for a lower P90, but also watch review latency, time to first review, and whether individual layers wait longer for approvals or CI.

The real test is not whether your team created stacks. It is whether reviewers received smaller changes that they could understand and finish reviewing sooner.

GitHub now provides the workflow. GitQuick shows whether the workflow changed the outcome.

GitHub announced stacked PRs on 30 July. GitQuick does not yet treat a stack as a first-class delivery unit: one connected piece of work rather than a list of separate PRs. Stack-aware analytics are under development. The intent is to keep each layer’s own metrics, and also to show the stack’s total review surface (the combined size of every layer presented for review), dependency waiting time (how long an upper layer sits idle because a lower layer is unfinished), completion time, and the blocking layer (the lowest open PR that is holding the rest of the stack).

If stacked PRs become part of your workflow, those measures are meant to answer the question GitHub cannot answer on its own: did the work actually become easier and faster to review?

The dashboards below are public. No GitHub installation is required:

• Vercel
• AWS
• All showcases

Then run GitQuick on your own organization and compare median PR size with P90. If the typical PR is small but the tail is not, inspect those large changes and decide which ones should have been split.

See your PR-size distribution →

Disclaimer: This analysis uses public GitHub metadata and GitHub’s own stacked-PR documentation. Lines changed are a size signal, not a measure of code quality or individual performance. GitQuick is not affiliated with or endorsed by GitHub, Vercel, AWS, or any organization mentioned.