The first stack I ever tried to review had a mermaid diagram in the description explaining which branch depended on which. It was heroic. It was also unrepeatable, and by the third PR I was clicking Approve on faith. Anyone who has tried to bolt Graphite or an in-house script onto vanilla GitHub knows the shape of that afternoon: the tool works, right up until someone force-pushes a base branch and the entire thing quietly desyncs.
GitHub's answer, per the DevOps.com report, is native stacked pull requests. The feature is in public preview and rolling out to all repositories over the coming days. Merge queue support is coming in progressively over the following weeks.
The stack, in plain terms
You split a large change into an ordered series of smaller, dependent PRs. Each PR sits on top of the previous one and represents a single layer. Every PR gets a stack map at the top so you can see where the layer you are looking at fits into the larger change.
The merge behaviour is the part that will make or break the daily feel. When the latest ready PR merges, it lands that change plus every unmerged layer beneath it in a single operation. In practice that means you review top-down and merge once, instead of dancing through the stack from the base up and rebasing every remaining branch after each merge. That rebase dance is the specific pain the feature is aimed at, and if the rollout holds up, it is the change you will feel first.
The CLI, the web, and the mobile piece
There is a new CLI extension, gh-stack. The feature is also supported on github.com itself, in the GitHub mobile app, and through GitHub Copilot via a dedicated skill. That is a broader surface than most third-party stackers cover today, and it is why this one has a chance of becoming the default answer inside GitHub-centric teams rather than a niche workflow you evangelise in your Slack.
What CI and platform teams should look at first
Existing branch protection rules still apply. Required status checks are maintained. Merge queues still function today, and deeper integration is on the way over the coming weeks.
The interesting question for pipelines is what "status" means for a layer whose base is another open PR. If your CI assumes a flat PR graph where each branch tests against main, a stack changes that assumption. When a middle layer changes, the status checks on the layers above it need to re-run against the new base. When the top layer merges and pulls three layers with it in one shot, your deployment tooling needs to see one merge event, not four. Both of those are solvable, but they are the sort of thing that hides in a Terraform module until the first real stack goes through it.
If you run required checks on merge queues, plan for the transitional window. The reporting says queues still work with stacks; the deeper mechanics are still landing.
Why smaller PRs pay off, with actual numbers
The DevOps.com piece cites analysis of 1.5 million pull requests: changes under 200 lines were approved roughly three times faster than larger ones and carried about 40% fewer defects, and each additional 100 lines added around 25 minutes of review time. Whether you buy those exact numbers, the direction matches what every reviewer has felt at 5pm on a Thursday, staring down a 900-line PR with a two-line description.
Two early adopters get named in the reporting: Vercel's Next.js team, who said they can ship larger features while keeping each PR small enough to review, and TED's engineering team, who cited AI coding tools generating oversized PRs as their motivation for jumping in.
The rough edges I'm bracing for
Stacked workflows have a mental-model tax past four or five layers. If a lower layer needs a genuine rewrite, the layers above it inherit the pain, and no stack map fixes that.
I also want to see how the Copilot integration behaves in a repository with tight branch protection. A skill that can propose, split, and land layers is convenient. It is also a fresh trust boundary in your PR flow, and one that most teams have not yet written a policy for.
And the queue window matters. Public preview, gradual rollout, merge queue integration still landing: that is three moving parts inside the same feature, all touching the code path where your production changes actually merge. Cautious teams will want to watch a couple of low-stakes stacks land end-to-end before they retire their scripts.
What I'm watching next
Real stacks under real deadlines, with more than four layers, and at least one middle layer that has to be rewritten mid-flight. If the merge event stays clean, if the status checks re-run predictably against shifting bases, and if gh-stack feels closer to git than to a plugin, this becomes the default. If any of those slip, the stackers we already use are not going anywhere. Tell me what happens on your first eight-layer stack. That is the interesting data point.
Top comments (0)