Image: GitHub Blog
On July 30, GitHub rolled out a feature to public preview that developers have been begging for for years and that entire startups held onto (Graphite, Sapling) — stacked pull requests, “stacks” of related PRs. The topic stayed at the top of Hacker News for two weeks (~780 points), and for a good reason: it changes how large changes are reviewed. For everyone who writes code and wrestles with gigantic PRs, here’s a straightforward breakdown.
What are stacked PRs
Usually each pull request targets the main branch. If the task is big, it becomes one enormous PR of about 2000 lines, which the reviewer looks at for a week, while you wait all that time.
Stacked PRs flip the approach: instead of one monolith you create a well-ordered stack of small PRs, where each targets not the main branch, but the layer beneath it. The first PR is the foundation, the second is built on top of the first, the third on the second, and so on. Each layer is a small, meaningful, self-reviewable change with a clear dependency on the previous one.
How it works in GitHub
- Creation: via the CLI extension (
gh extension install github/gh-stack), on github.com, in the mobile app, or through GitHub Copilot. Start from a base branch and PR, then add branches/PRs on top. - Review: each PR shows the diff only for its own layer, and above it sits a “stack map” — a map of how this piece fits into the overall work. Reviewers look at different layers in parallel, without blocking each other. All familiar branch protections and mandatory checks continue to work.
- Merge: you can merge everything with one button (which merges the top PR and all unmerged layers beneath it) — or merge the lower layers one by one, with the top PR automatically rebasing and re-targeting onto the new base. Manual rebasing of the stack has long been the main pain — GitHub now handles it.
Why this matters
There are many teams on forums managing their projects, scripts, and dashboards who face exactly these problems:
- Big PRs are a bottleneck. By breaking a feature into layers, you get quick reviews of small pieces instead of a week-long analysis of a monolith.
- Fewer branch-management hassles. Previously, maintaining a stack required manual handling through a chain of feature branches and constant rebases; now it’s built in.
- Review quality improves. A small, focused diff yields more precise feedback than a wall of text where the eye gets lost around the hundredth line.
Realistic assessment
No hype — the feature has boundaries.
- This is public preview, not a final release. Rollout is happening across repos over several days, and merge queue support is being added gradually over the following weeks; plan for that in critical repositories.
- The concept isn’t new. Stacked approaches have long lived in Graphite, Sapling, git-branchless, and
ghthrough third-party wrappers. The value lies in native support inside GitHub — without external services and with working branch protections. - It changes team habits. Stacked PRs require discipline in decomposing tasks; if your team is used to one big PR, expect an adaptation period.
- For a solo project with a couple of commits, this might be overkill — the feature shines with large features and team collaboration.
What to do
- Install the extension and try it on a real feature:
gh extension install github/gh-stack— that’s a minute, and it’s better to stack manually once than read about it. - Start with decomposition. Before building the stack, learn to slice a task into independently reviewable layers — that’s half the benefit.
- In active repos wait for the merge queue to catch up if you rely on it.
- Compare with what you already use (Graphite/Sapling): if a third-party tool works for you, native support will simply remove an extra dependency.
Sources
- Announcement of stacked pull requests at the GitHub Changelog
- Discussion on Hacker News (~780 points)
Do you already break large changes into stacks (via Graphite/Sapling or manually) — or still live with one big PR? Will native GitHub support work for you, or are external tools more convenient?