GitHub invokes spirit of Phabricator with preview of Stacked PRs
- Reference: 1776186199
- News link: https://www.theregister.co.uk/2026/04/14/github_stacked_prs/
- Source link:
[1]Stacked PRs , now in private preview, enable a pull request to be based on a previous pull request to form a stack. Each pull request in the stack can be reviewed and merged independently, provided that all the pull requests below it in the stack are merged first. It is also possible to merge the whole stack together.
There are several benefits to Stacked PRs, the most obvious being that they encourage smaller pull requests, which are therefore easier to review. "Each branch in a stack should represent a discrete, logical unit of work that can be reviewed independently," the [2]docs explain.
[3]
This is normally hard to achieve because developers typically want to continue working on code, even where the new code depends on earlier code that is not yet merged with the main branch. Waiting for each small piece to be reviewed and merged would cause too much delay, so instead they continue working in a separate branch until a feature is complete. The consequence is a large pull request with code changes in many files, which are hard to review.
[4]
Managing stacked PRs in GitHub
The Stacked PRs feature is new to GitHub, but familiar from other code management and review systems, where it is often called stacked diffs. One well-known example was Differential, created by Facebook's Evan Priestley and Luke Shepard in 2007. "I was spending a lot of time waiting for code review to happen, which was a major motivator for building the tool," [5]said Priestley. Differential became part of a suite of tools used by Facebook, called Phabricator, and was released as open source in 2011.
Open source Phabricator ceased development in 2021, though a fork called [6]Phorge remains actively maintained.
[7]Claude Code cache chaos creates quota complaints
[8]Microsoft developer chief Julia Liuson is logging off
[9]Microsoft calls time on ASP.NET Core 2.3 on .NET Framework
[10]Stack Overflow abandons redesign after loyalists criticize it
The developer workflow when using Stacked PRs is substantially different from that used without them. The bottom PR in a stack is normally based on the main branch, rather than a separate branch. Jackson Gabbard, who was an engineer at Facebook between 2006 and 2016, wrote a detailed [11]explainer in which he said "people who have worked with Phabricator using a 'stacked diff' workflow generally love it and seek it wherever they next go."
A [12]discussion of the feature on Hacker News is generally positive, though a developer [13]observed : "I don't quite see the need for this CLI [command line interface]. Git has had some additions in the last few years that make this work natively." The CLI referenced here is the new GitHub-specific extension gh stack . Nevertheless, building this into GitHub is a major change, and the CLI simplifies its use. GitHub's Sameen Karim, who has been working on the feature, [14]said that "the CLI is completely optional, you can create stacked PRs purely via the UI."
[15]
GitHub also has AI in mind. "The bottleneck is no longer writing code – it's reviewing it. Stacks help solve that," [16]said Karim on LinkedIn. The stack CLI is also designed for use by AI agents, Karim said. ®
Get our [17]Tech Resources
[1] https://github.github.com/gh-stack/
[2] https://github.github.com/gh-stack/introduction/overview/#thinking-about-stack-structure
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ad65A6yBakEPozTqDZV63gAAAk8&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://regmedia.co.uk/2026/04/14/stacked-pr.jpg
[5] https://secure.phabricator.com/book/phabflavor/article/project_history/
[6] https://we.phorge.it
[7] https://www.theregister.com/2026/04/13/claude_code_cache_confusion/
[8] https://www.theregister.com/2026/04/09/microsoft_devdiv/
[9] https://www.theregister.com/2026/04/08/aspnet_net_framework/
[10] https://www.theregister.com/2026/04/07/stack_overflow_retires_redesign_beta/
[11] https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/
[12] https://news.ycombinator.com/item?id=47757495
[13] https://news.ycombinator.com/item?id=47761360
[14] https://news.ycombinator.com/item?id=47758652
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ad65A6yBakEPozTqDZV63gAAAk8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[16] https://www.linkedin.com/posts/sameenkarim_excited-to-share-what-ive-been-working-on-activity-7448411477482430465-SYiT
[17] https://whitepapers.theregister.com/
terrible since it was invented
It has long been shown that small changes, continuously integrated, makes for fast progress.
This is a reaction to the symptoms of failing tech teams, where people get bored waiting for their change to be integrated, and they get told off for hanging around, so they have to carry on... on top of their unfinished, unintegrated work.
Fix your processes, so changes are integrated quickly. For most companies and software products, even in some regulated industries, your changes can be committed, reviewed and integrated in 10 minutes. Because they are small changes! No need for stacks!
If they can solve the problem of changes being needed in the lower part of the PR stack affecting all the ones that rely on it then this could be quite a nice feature.