GitHub Community
Stacked pull requests are now in public preview 🚀 #201439
Replies: 426 comments 240 replies
|
gh extension install github/gh-stack |
|
Hey @AnupRajput1234, To get started, you can run this command in the GitHub CLI 😄 |
|
My claude code workflow would love if the CLI allowed merging stacks as well. Further, when the stack requires a rebase, the "merge" button is still green and seems to attempt a merge that will inevitably fail, this is rather frustrating as it takes quite some time for the UI to reflect this |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Please show the PR approvals on the stack list and merge stack list! |
|
And gh actions status also! 🙌 |
|
Thank you for sharing your thoughts! We do show the "ready" status in the merge box. Are you referring to something else or you are asking to add the status to all the stacks views? 
|
|
|
It's what I'm looking for too. I have stacks of dozen of PRs and some PR have approved and some are not. It's really hard to tell from the list atm |
|
+1 yes totally. Also showing CI status completion would be great |
|
Idk if I did something wrong, but I did merge PR2 and then PR1 and only got PR1 merged to main. I had to merge main into PR2 and solve conflicts to be able to merge that one as well. In any case, I think it's not very intuitive what's going on; this was my structure:
|
|
Something similar here. I merged the PR1 into main (which i thought i'd have to do first), and then when I went to merge in PR2, it says "stack conditions not met" and I can't merge. No indication of what exactly that condition is. Guess I did something in the wrong order, but it's not obvious which order to do things in. |
|
Turned out that the conditions that weren't met were just my standard blocking tests not having run yet. The tooltip was just confusing since it referenced the stack, when it was really just that ticket. |
|
Yeah same, seems buggy ! |
|
Thanks for the 🥞! |
|
Can I unstack them so that I can merge things? Right now I have a PR to Branch A and cannot merge it because the PR from Branch A to Develop is blocking it, seems kind of dumb. |
|
It's the button in the top-right corner of this menu 
|
|
Terrible design choice, the unstack icon is so hard to find... |
|
Irritating that merging is all-or-nothing within a stack (for any PR above the bottom one). Why can't I just merge at least the top PR into the one below it to simplify the stack? |
|
@rbell-mfj 
|
|
unstack should be a green button with text. |
|
A share button that copies the links to each PR in the stack so I can share with my colleagues when asking them to review |
|
Or sharing the entire stack as a single thing. Sharing link to a page that displays the entire stack would be great also. |
|
It would be great if you made it so these new stack commands worked via github PATs - otherwise it will be a little dangerous with agents (you have to give them full access). |
|
this feature looks really promising, but I think it only becomes useful when a contributor who doesn't have access to the repo can stack PR submissions. unless I'm missing something, all branches must be in the same repo currently. They aren't when you submit a PR to another repo, and you might want to stack onto your first PR |
|
Even for non-public repos, having to grant write access to all contributors is an anti-pattern due to the lack of granularity in the GitHub RBAC model. |
|
This is a key missing piece of this feature in my mind. The typical workflow of finding a project you want to contribute to on GitHub is that you make a personal fork, and push your changes there, creating a corresponding PR in the upstream repo. And then you find another thing to fix, that touches the same code, but isn't a related feature. So your second topic branch and PR pulls in the commits from the first topic branch and PR. Super annoying for both contributors and reviewers to deal with. Crossing fingers cross repo stacked PRs will make it in before release! 😊 |
|
As an OSS maintainer I want to be able to stack up a number of community PRs so that we can merge them as one rather than having to rebase all PRs each time one is merged. Obviously the lack of signing support is also going to break this workflow in the same way it breaks the maintainer rebase button and rebase merge strategy. |
|
+100 to this. I can't believe this wasn't solved before initial release. This should be P0. |
|
I have a use case for this that would be greatly improved with a pretty minor change. Occasionally, I need to make a change that should be deployed in multiple separate steps. For example, removing an S3 bucket from a Terraform deployment - first I need to merge a change to enable force-destroy and apply that (so it can be removed without emptying its contents first), then I need to merge a second change to actually remove it. Stacked PRs look like a great way to create both PRs ahead of time and mark them as related for reviewers, but I don't see any way for the stack creator to force the individual PRs to be merged separately. In the case I described above, someone merging both of them at once defeats the purpose and causes a failed apply. If I could disable merging multiple PRs at once for a specific stack, it would be much more useful and safer for this use case. |
|
That makes sense, especially for infrastructure changes where deployment order matters. A per-stack option to enforce sequential merging could make stacked PRs much safer for workflows like Terraform. It might be even better if each PR in the stack could be marked as dependent on the previous one, so the next PR becomes mergeable only after the previous PR has been merged successfully. That would preserve the intended deployment order rather than relying on reviewers to remember it. |
|
I lowkey dislike the github stacks feature they added |
|
yea, my expectation was that I would be able to consolidate prs in the stack incrementally. That workflow exists with feature branches, just in a more cumbersome way, and I was hoping stacks would help make that process easier |
|
It even seems worse than that, because if I can't incrementally merge, then I have to respond to PR feedback in branching histories, so instead of starting on the leafs and reviewing and merging towards the trunk, I have to start at the pr closest to the trunk, and work my way out, resolving and re-resolving any merge conflicts along the way |
|
Yeah, I think that's one of the biggest limitations right now. Being able to merge an intermediate PR independently would make stacks much more flexible, especially when each stage needs to be deployed or validated before the next one is merged. |
|
It's a complete mess when using squash merges too. I thought it would auto-rebase the upstack PRs but that fails with merge conflicts due to the squash merge. I guess it only makes sense if (a) you're using merge/rebase commits and/or (b) you're going to merge the entire stack at once(?), though I'm not even sure that would work. |
|
It's also annoying when I try to make a stack of PRs into dev and someone else is making a PR from |
|
EDIT: Seems there is a phased rollout, as we now have support! This feature is not currently working for any repo in our organization that has a Merge Queue. Is there any guidance of how to enable this? I verified this to see 404 vs. 200 statuses for the stack feature against all of our repos. |
|
This sounds like an important compatibility gap, especially for organizations that rely on Merge Queue for protected branches. It would be helpful to know whether stacked PRs are currently expected to work with Merge Queue, or if repositories using Merge Queue are intentionally excluded during the rollout. If it is a rollout limitation, some documentation or an explicit UI message would also be much clearer than returning a 404. |
|
Also looking for more clarity here |
|
+1 this was super confusing to me. |
|
Would love an update here. |
|
My repo with a merge queue just got stacked PRs support today, not sure if everyone has it or if they're doing a staggered rollout. |
|
Nothing indicates that there is a conflict: 
Then, upon rebasing, a conflict exists on the 'current' PR 
And now I don't have the web editor option to solve the supposed conflict. |
|
yep same for me, and in the end I pulled manually master onto my lower branch, and there was actually no conflict at all (i don't know where it found it in the first place) |
|
Same here, tried different times, not working. I have to it manually |
|
came here to post the same issue , the new stacking PR feature is not indicating the merge conflicts |
|
I don't think this "stacked PR" feature works at all with squash merging into main. We already stack PRs (P1 -> main, P2 -> P1, P3 -> P2, etc) and I thought the merge conflict issue with squash merging + stacked PRs was solved by this feature, but it really doesn't seem to provide any discernable benefit. I can't even squish my PR branches down to one commit and use merge/rebase commits without having the same problem. |
|
Would be nice to be able to mark a whole stack as "ready for review" at once |
|
Thank you for the feedback! Sharing this with the team |
|
adding onto this it would be nice to be able to assign the same reviewer to a given stack. often you need the context from previous layers to review a given layer. |
|
All commits before the stack are suddenly unverified even though no changes were made to my local signing ability, any commits pushed up after stacking are verified as usual |
|
We experienced this same issue, and it makes stacked PRs unusable in our org. As soon as Github tries to rebase the second PR in the stack against the post-merge of the first, the commit becomes unverified, and the stack merge stops. Also, some CI checks seem to either block the stack (because they are required, and are not run or cannot be run) or cause a timeout (because the CI checks take a long time). I would expect the following:
|
|
We're facing the same issue with the author and squash-merge. While the feature is generally amazing, this is a blocker. |
|
The team is currently working on a fix. Thanks for sharing 🙏🏼 |
|
@imanmahjoubi can we expect a timeline on when this is fixed? This has bitten our team multiple times already, and I'm honestly surprised this bug even went into production considering the main responsibility of GitHub is managing commits correctly… |
|
The "author/email address" bug is still there as of today. |
|
The PR Stack is a nice feature. What would be an improvement to it, is a message about next PR in the stack after merging. Right now, after I merge a PR, I get these new messages:
So a nice addition, to make the work with Stacks flow nicer, would be a message
So that after clicking "merge" on current PR, I don't have to scroll to find the next one. |
|
This feature does not work well with the "Dismiss stale pull request approvals when new commits are pushed" branch restriction. I expect that if merging a stack of approved PRs, pushing the first one on the stack should not dismiss the approvals on the next ones. |
|
Came here to say just this. It's pretty frustrating to add a stamp of approval on all the PRs in the stack and then have to go back through each one by one. Disclaimer: Have only used stacks a bit and also not sure if this holds true if you merge the entire stack. |
|
Same thing with "Require approval of the most recent reviewable push" it also blocks merging a stack |
|
UX Feedback: It's not clear what will happen when I press the "Create Stack" green button. As a developer, I expect it to so some kind of dangerous action (e.g. merge all at once). It should be clear in the UX what it will happen. Right now it's not clear at all. 
|
|
I love the feature. It would be great if we could mass-delete downstream branches. If I have a stack of 10 PRs and I don't merge a single one until the tenth, I'm good to come back to every PR one-by-one to delete the branch after merging. It's cumbersome. A "Delete branches" action after merge would be more than welcome. 👍 |
|
I'd like to have the option, as a reviewer, to be able to see the whole stack diff in one go. The opinions of the authors in how to divide the work doesn't necessarily come structured or align with the view of the reviewer. |
|
As a reviewer, I would like the option to easily see changes of the full stack, also from any specific branch to a higher one. |
|
As a user of stacked PRs, it would be nice to have the option to require passing checks only for the top branch, prior to merging the full stack. |
|
It seems once you created a stack you can't change the base of the stack. If you create the stack based on a branch that later gets merged, you're stuck. I can't find an option to change the base of the stack, and you can't change the base of the first stack-PR because it's part of a stack, and GH just shows an error on the PR: |
|
Coming from Aviator, there's two features I'm really missing:
|
|
Feature request: squash stack "frame", but rebase stack. I had to push another commit to a branch of the stack—a "frame", I suppose?—to fix an issue in the build. After everything passed, I choose to rebase and ended up with 3 commits instead of 2. I mean, technically, it did what I told it. But the way I've been doing stacked PRs manually for years—based on In my case, I use conventional commits and didn't think to push this build fix as a conventional commit thinking it'd get squashed out of habit, but no. |
|
GitHub Web automatically deleted my local and remote branches when I merged PRs at the bottom of the stack. This made it impossible to use |
|
It would be nice to have a |
|
I'd be awesome if we could add a stack-wide reviewer using auto-assignment for stacked pull requests. Today, when a I’d love to see an option to assign the same reviewer across the entire stack, so one person can review the full change set consistently from bottom to top. A useful implementation would be a team auto-assignment mode that selects one reviewer for the whole stack instead of evaluating each PR independently. I've submitted this a ticket for GitHub to consider, but if anyone in this thread has a workaround that'd be greatly appreciated! 🙏 |
|
Merging a stack doesn't work for me, and support told me to go away (link). How does one report a bug? |
|
Pushing or syncing the stack does not map each branch's upstream, so further work does not show that it's been pushed, nor what the difference is. This should be automatic, esp if git is configured to to the same on plain 'git push' via "push.autosetupremote=true". Especially confusing if you have a prompt that shows diff between yours and upstream/remote branch. But, this is pretty awesome. I like it a lot so far! |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Stacked pull requests break large changes into small, reviewable pull requests. They're an ordered series of pull requests that each represent focused layers of your change. With stacks, you can independently review and check each pull request, then merge everything together in one click. No more opening a single large pull request that takes forever to review, or splitting work across multiple branches you have to keep manually rebasing.
072926-gitub-tmp-pr-v08.mp4
With stacked pull requests, teams can:
main.And because stacked pull requests are built into GitHub, your existing reviews, checks, and merge requirements all work out of the box.
Get started with the CLI extension
Install the CLI extension and create your first stack in under a minute:
Create stacks from your terminal or github.com
Create a stack from github.com, the GitHub CLI, the GitHub mobile app, or with a coding agent such as GitHub Copilot using the gh-stack skill. Start with a branch and pull request for your first change. Then add branches and pull requests on top of it; each pull request targets the layer below it.
Stacks-Changelog-InLine-01-CLI.mp4
Review each layer independently
Open any pull request in the stack to review only the diff for that specific layer. Use the stack map at the top of the pull request to see how the change you're reviewing fits into the larger work. You and your teammates can each review different layers in parallel without blocking further work.
Merge everything in a single click
Merge the latest ready pull request to land it and every unmerged layer below it in one single operation. To land part of a stack, merge one or more lower layers—the pull requests above it stay open and automatically rebase and retarget. Your existing branch protections and required checks still govern what reaches
main.Stacks-Changelog-InLine-03-MergeBox.mp4
Find out more and share your feedback
Stacked pull requests are rolling out in public preview to all repositories over the coming days. Merge queue support for stacked pull requests is rolling out progressively over the coming weeks.
For more information, check out the stacked pull requests documentation, and share your feedback with us in the comments below!
All reactions