GitHub Stacked Pull Requests Now Live in Public Preview
Stacked PRs are now live on GitHub
GitHub has launched stacked pull requests in public preview, allowing teams to break large changes into small, reviewable layers. You can now review each layer independently and merge the entire stack with a single click. This new feature eliminates the need for manual rebasing and helps maintain code quality while accelerating the delivery of complex features across repositories.
A big change used to mean one giant PR nobody wanted to review. Now it's a stack of small ones reviewers can actually follow, and the whole stack merges in one shot.
- matharmin
I've been using the preview for a bit, and I'm quite surprised to see them expanding the preview with so many unfixed issue.
For example, merging an entire stack is completely broken in many cases: https://github.com/github/gh-stack/discussions/212
You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably the biggest gain of stacked PRs.
The command line tooling (gh stack) helps to make things slightly less manual, but you still need to be very aware of how git rebase works, the tooling just helps automate it across multiple branches. For example, just running the "gh stack rebase" commands that the UI suggests won't work if your local branches are not in sync with the remote ones, and the tooling won't point that out to you.
I do find the stack UI quite nice. It's quite minimal compared to standalone PRs, but it's enough to show the relationship between them.
(My comments all assume you already have a good reason to stack PRs. This tooling just help to make the workflow easier, it does not give any new capabilities)
- sameenkarim
Hey from the GitHub Stacked PRs team!
Excited to release this more broadly so anyone can start stacking: https://gh.io/stacks
Would love to hear any feedback, especially with the UI and CLI. We've got a lot more updates to the PR experience in store!
Also happy to answer questions about the design decisions we made. There's a bunch happening behind the scenes, and it's one of the largest launches in GitHub history covering almost every service from Actions and protection rules to the CLI and mobile apps.
- steveklabnik
This is one of the biggest changes to hit GitHub in many years. I'm really glad to see something like this deployed to one of the largest forges in the world, hopefully it will expose a lot of developers to workflows that they didn't even know about before.
If you buy the idea that stacking produces better software, then this also has the opportunity to really help out quite a few people.
- Okkef
What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit?
I think the bigger problem is that big AI PR's need a different way of reviewing. For example, the order in which the diff's are shown can make a big difference in how easy the commits are to read (e.g., function definition change first, then all call sites, then the tests).
Or maybe we should go to a system where diffs & comments are intertwined, a bit like how "Literate Programming" intertwines code and prose.
Literate diffs / literate pull requests... I haven't found anything like that yet.
- chill_ai_guy
Probably a few years too late on this. Its for a time when humans still reviewed PR's. For better or worse, that is a thing of the past. The review step has shifted heavily left and newer re-imagination of Git (like Origin) will almost certainly not have a concept of a "PR" let alone stacking them
- lucky_cloud
Is that why the menu toggle is the stack of pancakes emoji (U+1F95E)?
Whimsy is fine but that change made me super suspicious about what I was looking at.
- shoyer
When will this support "trees" of pull requests, with dependent changes? In my experience with stacked changes (from Google), it is often the case that changes do not stack up as a linear history. I imagine that would especially be the case these days with parallel coding agents.
- ozozozd
So, it was hard to review 1000 lines in one PR.
And we solve this by splitting into 2 PRs that still merge at the same time. Oh, super useful!
Only if your reviews are so shallow that you don’t try to reason about the state of PR B merged to PR A, which would then be merged to main, and your real problem is just GitHub UI failing to handle a giant PR, which we all know that this feature is attempting to help with.