GitHub shipped Stacked PRs, now what?

Hey {{first name | there}}. This past week, GitHub shipped stacked PRs, and developers everywhere are jumping for joy.

But why is this? And after 18 years of operation, why has GitHub just shipped a long-awaited feature?

In today's Technical Notes:

🧠TOGETHER WITH AWS

Divine went to re:Invent 2023 to answer questions his team was stuck on. 

His team was building a database on Kubernetes platform, and was stuck on which operators and k8s flavors to back. 

At a session on data platforms with Aurora, RDS, and Kubernetes, the room split on provisioning through Terraform versus ACK. He went in thinking that was a preference question and left understanding it was really about who owns the database lifecycle. 

That is the kind of thing you get from a conference room, not a recording on YouTube.

re:Invent 2026 runs November 30 to December 4 in Las Vegas. 

Around 70% of sessions are hands-on, experts like “Jeff Barr” are onsite for the questions support tickets cannot answer. Also, certification exams are discounted there.

The $1,200 early bird discount ends August 25.

Register with the discount → https://bit.ly/4w4HGIR

Thanks to AWS for your partnership and for sponsoring this newsletter.

Before we get into how this happened, it is important to understand what stacked PR’s are and how they differ from the existing pull request workflows you might be used to.

When building out a simple feature on a given application, the default path is to start a feature branch, make your changes, and then create a single pull request.

This works great for self-contained features; however, if a feature depends on the existence of another feature, you need some way to “layer” it on top of each other.

Well, this is how stacking works: instead of piling every dependent change into one branch, you split the work into a chain of small branches, each one built on top of the last.

Say you are shipping a feature that needs a database migration, a new API endpoint, and a UI change. In a stack, the migration is PR #1 targeting main, the endpoint is PR #2 targeting the migration branch, and the UI is PR #3 targeting the endpoint branch. 

Each reviewer only sees the diff for that one layer, not everything underneath it. When PR #1 merges, PR #2 retargets to main, and the process repeats until the whole “stack” has landed.

When your work has dependencies, the traditional flow leaves you with three options, and none of them are good.

Option one: wait. You open PR #1 and wait until it merges before starting the dependent work

Option two: branch off your own unmerged branch and manage the stack by hand. Git itself is fine with this, but the tooling around it is not. Open a PR from that second branch and GitHub shows the diff against main, which means it includes every change from the first branch too. 

Your reviewer is now rereading code that is already under review somewhere else. And when PR #1 gets review feedback, you are stuck manually rebasing every downstream branch and force-pushing each one.

Option three: cram everything into one big PR. This is what most teams settle on, and it is why the 2,000-line pull request exists. Big PRs get worse reviews, not proportionally worse, 

Past a few hundred lines, reviews become more skimming, and “LGTM” stops meaning “I checked this” and is closer to “I trust you.” 

I first became aware GitHub had something in the works after seeing this tweet from cassidoo, and three days later it was real: stacked pull requests hit public preview on July 30, and GitHub swapped the navbar hamburger for a 🥞 emoji to mark the week.

However, there were several questions around why it took so long for the world's largest developer platform to bring this to life.

Sameen Karim, who works on the product team at GitHub, took to Twitter (formerly X) to describe in detail the challenges surrounding this highly requested feature. 

Here are some highlights 

Stacked PRs are a public preview, not a finished feature, and the gaps are real: no auto-merge, no stacks across forks, and squash merges still have rough edges. But the direction is set, and it changes the decision for a few groups of people.

If your team pays for tools like Graphite or maintains ghstack scripts, you now have a reason to put a review date on that dependency. If you never adopted stacking because bolting it onto GitHub felt like too much, that objection is gone, and it is a native workflow now. 

And if your team’s default is still the giant catch-all PR, this is the cheapest opening you will get to change that: install the extension (gh extension install github/gh-stack), stack the next feature that has a dependency in it, and see whether review turnaround actually improves.

💡PRESENTED BY AWS

Divine went to re:Invent 2023 to answer questions his team was stuck on. 

His team was building a database on Kubernetes platform, and was stuck on which operators and k8s flavors to back. 

At a session on data platforms with Aurora, RDS, and Kubernetes, the room split on provisioning through Terraform versus ACK. He went in thinking that was a preference question and left understanding it was really about who owns the database lifecycle. 

That is the kind of thing you get from a conference room, not a recording on YouTube.

re:Invent 2026 runs November 30 to December 4 in Las Vegas. 

Around 70% of sessions are hands-on, experts like “Jeff Barr” are onsite for the questions support tickets cannot answer. Also, certification exams are discounted there.

The $1,200 early bird discount ends August 25.

Register with the discount → https://bit.ly/4w4HGIR

Thanks to AWS for your partnership and for sponsoring this newsletter.

That’s it for this issue. If you try the stacked PRs preview, reply and tell me how it goes, especially if it breaks. See you in the next one!

Know an engineer wrestling with this? Share this link with them

Jubril Oyetunji
CTO, EverythingDevOps