Stacked pull requests are now in public preview 🚀

[ebndev]

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.

"We've been using GitHub stacked PRs for Next.js for the past few months. It has helped us introduce smaller individual changes while shipping larger features, making it easier to review PRs. - Tim Neutkens, NextJS lead, Vercel"

072926-gitub-tmp-pr-v08.mp4

With stacked pull requests, teams can:

• Keep large changes moving by reviewing short, narrowly scoped pull requests in parallel.
• Maintain quality across every layer by using focused pull request reviews alongside existing branch protections to protect main.
• Merge one, some, or all by landing an entire stack altogether or individual layers one at a time.

And because stacked pull requests are built into GitHub, your existing reviews, checks, and merge requirements all work out of the box.

"The new Github Stacked PRs preview is incredible. Landing 5 stacked PRs directly to a merge queue all at once! A+++! This removes so much friction (and the gh cli tools + agent skill help a ton)" - John Resig, creator, jQuery

Get started with the CLI extension

Install the CLI extension and create your first stack in under a minute:

gh extension install github/gh-stack

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.

"AI has made TED's developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling. Stacked PRs help to solve that. By breaking large changes into small, dependency-ordered pieces, review happens in smaller logical chunks - not just faster PR reviews, but more accurate ones. Stacked PRs tighten our feedback loop and help get stable code to ted.com faster." - Andy Merryman, CTO, TED

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.

"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. It stopped feeling like a tool on top of GitHub and started feeling like GitHub." - Mayank Saini, connectivity engineer, WHOOP

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!

[AnupRajput1234]

gh extension install github/gh-stack

[ebndev]

Hey @AnupRajput1234,

To get started, you can run this command in the GitHub CLI 😄

[jens-gilion]

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

[jcaudill-truepic]

Please show the PR approvals on the stack list and merge stack list!

[victorDigital]

And gh actions status also! 🙌

[imanmahjoubi]

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?

[justinoboyle]

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?

Ready implies to me more of a status check then the approval status - a small indicator that it has been approved separate from required status checks would be helpful! (e.g. "Approved but required CI failing" is a different piece of information than "Waiting for approval, but all the checks are good to go")

[alvis]

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

[fgr-17]

+1 yes totally. Also showing CI status completion would be great

[felixminom]

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:

• main
  • PR1
    • PR2

[daprezjer]

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.

[daprezjer]

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.

[theophanemayaud]

Yeah same, seems buggy !

[benjaminclauss]

Thanks for the 🥞!

[binghamtj]

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.

[gracewhitney]

It's the button in the top-right corner of this menu

[diegorubert]

Terrible design choice, the unstack icon is so hard to find...

[rbell-mfj]

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?

[ckhall]

@rbell-mfj gh stack modify then fold the one PR into the other PR and apply.

[gilescope]

unstack should be a green button with text.

[ImErvin]

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

[d-feliz]

Or sharing the entire stack as a single thing. Sharing link to a page that displays the entire stack would be great also.

[isaksky]

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).

[dxqb]

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

[stevehipwell]

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.

[torarnv]

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! 😊

[stevehipwell]

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.

[MichaelChirico]

+100 to this. I can't believe this wasn't solved before initial release. This should be P0.

[jglick]

github/gh-stack#18 (comment)

[ghicks-novaprime]

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.

[Ritik574-coder]

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.

[FatTailSec]

I lowkey dislike the github stacks feature they added
[2:19 PM]no ability to merge intermediate stages its all or one into the default branch

[bienjamon]

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

[bienjamon]

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

[Ritik574-coder]

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.

[kyle-query]

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.

[beakrtobi]

It's also annoying when I try to make a stack of PRs into dev and someone else is making a PR from dev into some-other-branch. The auto detect now only lets me create a stack that includes the dev --> some-other-branch PR.

[nalvelo]

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.

[Ritik574-coder]

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.

[joerobot]

Also looking for more clarity here

[KyleBastien]

+1 this was super confusing to me.

[seanmsmith23]

Would love an update here.

[JarredAllen]

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.

[JeremasPosta]

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.

[MarionToutant]

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)

[jcrodriguezu]

Same here, tried different times, not working. I have to it manually

[SaiShankar93]

came here to post the same issue , the new stacking PR feature is not indicating the merge conflicts

[kyle-query]

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.

[danilofuchs]

Would be nice to be able to mark a whole stack as "ready for review" at once

[imanmahjoubi]

Thank you for the feedback! Sharing this with the team

[chrismikehogan]

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.

[BethelH]

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

[jsync-swirlds]

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:

1. The commits to be merged are frozen when the stack merge begins, and cannot change during the stack merge.
2. When merging a stack, CI must pass before starting the merge, so it should not be re-run during the merge.
3. Approvals are considered prior to the stack merge, and are not dismissed during the stack merge.

[pavel-mikula-sonarsource]

We're facing the same issue with the author and squash-merge.
Even the 1st PR in queue was reassigned to the reviewer as the author.

While the feature is generally amazing, this is a blocker.

[imanmahjoubi]

The team is currently working on a fix. Thanks for sharing 🙏🏼

[Maxr1998]

@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…

[thomass-dev]

The "author/email address" bug is still there as of today.

[V-iktor]

Stacks seem to lock branches in merge conflict state. Usually I have to change the base branch, then change it to the original base branch again to make Github realise there are no conflicts.

Not sure if this is directly related to stacks, but I have to unstack the PR to be able to change the base branch so Github stops blocking merge because of a non existing merge conflict.

[junkpiano]

For example, given main -> PR1 -> PR2 -> PR3 -> PR4 -> PR5 -> PR6,
I'd like to split this into two separate stacks:

• Stack 1: main -> PR1 -> PR2 -> PR3
• Stack 2: PR3 (base) -> PR4 -> PR5 -> PR6

GitHub's stacked PR docs only describe a single linear chain per stack, so this doesn't look supported today.
Is branching a stack on the roadmap?

[adjerbetian]

Feature request: set upstream tracking on gh stack submit / gh stack push

SImilar to this previous comment.

Problem

After gh stack submit (or gh stack push), remote branches exist on GitHub and PRs are created/updated, but local stack branches have no upstream configured.

That makes everyday git workflows awkward: git status doesn’t show ahead/behind vs remote, and git pull / git push without extra args don’t target the right remote branch.

Expected behavior

After a successful push of a stack branch to remote R, gh-stack should run the equivalent of:

git branch --set-upstream-to=R/<branch> <branch>

for each branch that was pushed.

Why a global git setting isn’t enough

push.autoSetupRemote only reliably applies when pushing the current branch. submit pushes each stack branch in order without checking them out, so only the branch you’re on might get an upstream; the rest typically don’t.

Implementation note (optional)

The codebase already has SetUpstreamTracking and uses it when pulling branches during checkout/sync. The same helper after each successful push in submit / push would likely cover this case.

Environment

• gh stack extension: v0.1.0 (github/gh-stack)

[darwindanboyle]

Bug Summary: Stacked PR merge box shows "Not ready" without explaining that an unresolved review thread is the actual blocker.

Feature: Native stacked pull requests (public preview)

What happened:
I had a 4-PR stack. The bottom PR had a required approval and all status checks passing, but the merge button wasn't available, and the stack widget at the bottom of the PR just displayed "Not ready" with no further detail or link.

Root cause (found via the API, not the UI):
Our org has a repository ruleset requiring required_review_thread_resolution: true. The PR had one unresolved review thread — a suggestion comment that had been bundled inside the same review action as the approval. Because the approval was visually prominent, the accompanying unresolved suggestion was easy to overlook, and the stack UI's "Not ready" status gave no indication that a review thread — as opposed to a check or a missing approval — was the actual blocker.

On a standalone (non-stacked) PR, this same situation normally surfaces a clear banner (e.g., "X unresolved conversation(s)") right above the merge button. That messaging doesn't appear to carry over to the stacked-PR merge box/stack-map widget.

Impact:
I had to use the GraphQL API (reviewThreads query filtered on isResolved: false) to diagnose why the PR was blocked, since nothing in the stack UI pointed at the actual cause. This is a rough experience for anyone not comfortable dropping into the API.

Suggestion:
When a stacked PR's merge is blocked specifically due to unresolved review threads (or any other rule violation type that a standalone PR would normally surface explicitly), please carry that same specific messaging into the stack-aware merge box/stack-map widget, rather than a generic "Not ready."

[MTRNord]

I am not sure if this was mentioned elsewhere before but I have this branch setup currently:

(in https://github.com/matrix-org/matrix-conf-website/ )

It seems I can only stack one lane but not each variant of the tree.

Ideally I would want 3 stacks here. Possibly 4 depending on how to split it.

• One for 258
• One for 259
• One for 255

These are the actual feature branches.

Depending on how the system can split it/deal with it it my make sense to have a dedicated stack for 260 + 261 here as well thats the basis of the other 3?

Ending up with these stacks:

• 260 + 261 (Stack A)
• 260 + 258 (Stack B)
• Stack A + 259
• Stack A + 255

I am not entirely sure whats best in the end but at least the current solution where only one branch stack is possible for this scenario is a bit annoying and limiting. I for now for example only end up doing 260 + 261 and the other ones are not stacked.

[anton-kolchunov-sumup]

Why not try to flatten branches even so changes are not really depending on each other? As I understand, you would like to get CI/AI feedback sooner on each PR as well as give possibility to review changes individually and most probably merge the whole stack. Having flat history will not harm, I think.

Otherwise, why to use stacked PRs for all branches? Build one stack (e.g. 260 -> 261 -> 255), 258 and 259 as regular PRs once stack is merged.

[MTRNord]

The reason we do it like this is that in the past the team gave me feedback that it is annoying to end up reviewing the same big chunk of shared logic multiple times. So I split it out into the 260 and 261 ones.

But I also see your argument here. Though the features (255, 258, 259) can also be merged in any order as they dont depend on each other. So 255 in the stack isn't ideal here since it likely is only merged just before the conference is starting. Meanwhile the others likely before in whatever order ends up working for us :)

I guess its not the ideal/classic usecase for stacks. In a way I am trying to use it for code duplication here across 3 features that are all looked at independently.

[MTRNord]

I think what I am looking for here is maybe more of a dependency chain than a merge relation. In a way like gerrit dependencies work. Which allows me those 1:N:N relations which this doesnt seem to allow?

[mcintyre94]

The CLI seems to mess up new lines in gh stack submit, I think it's reflowing the commit message based on the width of the terminal. So git commit with a terminal editor works correctly and can display a long line over multiple terminal lines while saving it as one line. But then when you submit it with gh stack submit the preview there adds actual newlines when it reflows the text. And it ends up being narrower than it needs to be and flowing weirdly in the GitHub UI.

[MoonstarCoding]

Bug Summary: Stacked PR merge is blocked even though all items within are "Ready" for merge.

Feature: Native stacked pull requests (public preview)

What happened:

On our staging branch, we have enabled branch protections and enabled some rather strict rules - such as requiring Code Owner approvals, requiring third party reviews when an AI is involved, requiring our CI/CD workflows to succeed, etc...

Regardless of these rules though, this bug will still occur when every branch in the PR stack is showing that squash and merge is a legal action and the stack is ready for merge.

When using the front-end, we click the button to merge the stack, and all items in the stack will go into the "Merging" state with the purple banner. After a brief period typically being no longer than 20 seconds, the branch state will return to the green banner-ed "Ready" state, and the merge will not have occurred.

Using the gh stack merge command grants clearer insights into what is happening. Upon merging, an error message is produced stating:

 ❯ gh stack merge
 ✗ merge failed: Repository rule violations found
 At least 1 approving review is required by reviewers with write access.

Again, the front-end is showing all PRs as ready for merge, all of those who have approved the stack PRs do have write access, so I am not understanding why this is occurring.

Impact:

This feature is unusable by our team until this is fixed.

[mcintyre94]

This might be a dumb question but why doesn't gh stack submit add the PRs to the stack in Github if there are existing PRs for earlier branches in the stack? The UI shows that it can be added to the stack and it works fine if I ask it to add it, but I'm not sure why this is a manual step rather than automatic.

[ento]

This stack is out-of-date with its base branch

I have a moderately high-traffic repo at work. The repo uses Merge Queue to ensure tests pass with the base branch merged in, and Pull Requests aren't required to be up-to-date with the base branch before merging.

However, with stacked PRs, it seems it becomes a requirement that they're up-to-date with the base branch before merging. This makes it harder to merge stacked PRs, since by the time CI finishes running against the rebased branch tip, there's a good chance that someone else merged a PR and the stacked PRs become out-of-date again.

Note: we use squash-merge.

[benlangfeld]

Stale review dismissal completely blocks the ability to merge a stack: github/gh-stack#323

@imanmahjoubi is this going to get looked at?

[tbrlpld]

The meaning of "sync" is not clear to me. Since it's not a term that is otherwise used by git or GitHub, it would be great to expand the help text a bit more than "Sync the current stack with the remote".

Also how to I get the remote changes to a stack pulled down to a machine when I have worked on that stack before?

[cohei]

Since early August, some commits that land via Rebase and merge have no associated PR: GET /repos/{owner}/{repo}/commits/{sha}/pulls returns [], so blame → PR no longer works.

In one private repo (rebase merge only), all multi-commit rebase merges through July 24 are fully associated. From August 5 on, 15 commits are missing. Each is a non-last commit of a multi-commit PR, in both stacked and non-stacked PRs. The last commit is always associated.

The timing matches the stacked PRs preview, so I suspect a related change in the merge path.

[CharlesT-Panther]

I submitted a stack and I listed the branch names in git log order, and so gh stack just submitted the latest branch and barfed on all the rest. It seems it would be trivial for gh to support reordering the branches since they depend on each other, or literally just let me submit my base and feature branch and infer the intermediate ones.

[izz-linux]

Stack merge fails "Waiting on code owner review" when the ruleset dismisses stale approvals, even with every PR approved at its head

What happened

Merging a 7-PR stack with "Squash and merge stack", and with gh stack merge <stack> --squash (gh-stack
v0.1.1), fails with "Repository rule violations found. Waiting on code owner review from /." The
merge is atomic, so nothing merged. Before confirming, the stack panel shows "Able to merge as a stack" and
every PR as "Ready".

Setup

• A branch ruleset on the default branch with a pull_request rule: required_approving_review_count 1,
  require_code_owner_review true, dismiss_stale_reviews_on_push true, require_last_push_approval false
• Required linear history; squash merges only
• CODEOWNERS on the default branch: * @<org>/<team>
• A native stack of 7 PRs. Each branch was brought up to date by merging its base into it, with plain merge
  commits pushed as fast-forwards. No rebase or force-push.
• After the last push to each branch, one code owner approved every PR. Each approval is at that PR's
  current head SHA, GraphQL shows each review on behalf of the code-owner team, and every PR reports
  reviewDecision APPROVED and mergeStateStatus CLEAN.

What we tried

• Setting require_extra_approval_for_unattributed_changes to false: still fails
• Turning off "Dismiss stale pull request approvals when new commits are pushed": the same stack merged at
  once, with no new pushes and no new reviews

Expected

An approval given at a PR's current head should count as a fresh code-owner review when the stack merges.
Dismissing stale approvals should only affect approvals given before a later push.

Likely cause (our reading, not confirmed)

Each PR in a stack is evaluated against the stack base. The approvals may be judged stale against that
comparison rather than against the PR's own head, so the code-owner requirement reads as unmet.

Also

The pre-merge check ("Able to merge as a stack", every PR "Ready") disagrees with the rule evaluation at
merge time.

Workaround

Turn off dismiss stale approvals, merge the stack, then turn it back on.

When

2026-10-02, stacked pull requests public preview, gh-stack v0.1.1

[benlangfeld]

This is a duplicate of github/gh-stack#323.

[sammillerwriter]

One improvement I would really like to see is better control over how stacks are created and merged.

The current linear stack model works well when every PR strictly depends on the layer below it, but real workflows can have multiple independent branches sharing the same base. In those cases, forcing everything into one linear stack can create unnecessary coupling.

It would be useful to support:

Choosing the base branch when creating a stack.

Creating multiple stacks from the same parent branch.

Treating PRs as dependencies without requiring them to be merged together.

Setting a per-stack merge policy, such as sequential-only merging.

Showing the exact rule, approval, or CI check preventing a stack from being merged.

Allowing intermediate PRs to be merged independently without restructuring the entire stack.

This would make stacked PRs much more predictable for teams with development, staging, and production branch workflows.

The same principle applies to content teams managing many independent changes, such as updating a product page for Custom Frozen Pizza Boxes while other unrelated pages are being worked on. Not every change belongs in the same dependency chain.

Overall, the feature is useful, but giving repository owners and stack creators more control over dependency and merge behavior would make it safer for more workflows.