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!

[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

[mars3jx]

same.

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

[zleigh-digistorm]

Same issue. Getting phantom merge conflicts that I can't resolve.

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

[harrydowe]

After the base of the stack is merged into main, doing gh stack modify is broken because it's still referencing the now removed branch so some files in .git/gh-stack need manually updating or the branch restored

 gh stack modify
✗ failed to apply modifications: building snapshot: resolving branch SHAs: failed to run git: fatal: ambiguous argument 'branch_name': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

[tales-raponi]

Feature request: merge an upper layer into the layer below it, without unstacking

Today a stack only merges bottom-up, into the trunk. We'd like to merge an upper PR into its parent's branch. That would fold the stack down one layer at a time, until one PR is left against the trunk.

Our workflow

1. A base PR targets an environment branch (development, sandbox, staging or production). It is usually the epic: epic → development.
2. Upper PRs add to that base PR, each one built on the branch below it: epic ← feature/X ← feature/Y ← …
3. The reviewer approves top-down. Each upper layer is merged into its parent once it's approved. The epic is the last to go: it is merged into the environment branch after a final review of the combined change.

What happens today

Upper layers can't be merged while they're in a stack. To fold the stack, we have to unstack it (gh stack unstack <n>), merge each layer into its parent by hand, top to bottom, and give up the stack view for the rest of the review.

What we'd like

• A way to merge layer N into layer N-1's branch while the PR stays in the stack, so the stack shrinks by one.
• The same rules as a normal PR merge into that branch: required reviews and checks of the target branch apply.

This would let stacks fit teams that use the bottom PR as an integration branch, not only teams that ship each layer to the trunk.

[malbertSC]

If I have my main branch protected with "Require approval of the most recent reviewable push", I'm able to merge a full stack of PRs against main without needing re-review or re-running CI checks, which is great. However, If I merge part of the stack, any PR higher in the stack gets their reviews dismissed. That seems inconsistent and unnecessary, it's kind of a disincentive for merging PRs lower in the stack as they're ready. Is that intentional, or a bug?

[awhitney-sqsp]

With a fair amount of LLM-generated code on my small team, human review is by far the bottleneck, and stacks are a great tool for streamlining those reviews! However, sometimes code generation gets even further ahead of human review, and there are multiple entire features that depend on each other in review - say, big-feature-A is a 6-PR stack, and big-feature-B, which depends on big-feature-A but requires different background context to review, is another 3 PRs that branch off the end of the big-feature-A stack. I'd like to be able to make a "separate" stack for big-feature-B, while still having the base branch for that stack be the end of the big-feature-A stack rather than main.

By "separate" I mean:

• stack dropdown in the PR UI only shows the big-feature-A PRs when you're looking at a big-feature-A PR, and only shows the big-feature-B PRs when you're looking at a big-feature-B PR
• merging the big-feature-A stack wouldn't attempt to merge the big-feature-B PRs (though it would be great if the bottom got automatically re-pointed to main at that point, as it would if it were part of the big-feature-A stack)

Instead, when I dropped my big-feature-B PRs from the big-feature-A stack and then attempted to gh stack init feature-B-1 feature-B-2 feature-B-3, the existing PR for feature-B-1 into feature-A-6 was suddenly retargeted to main, and the reverse operation - gh stack add feature-B-1 feature-B-2 feature-B-3 onto the existing feature-A stack - did not retarget that PR back to feature-A-6 but instead wanted to create a fresh PR for each feature-B branch on gh stack submit. (In this case all the feature-B PRs are still drafts so there's no review history to be lost, fortunately; just my hopes that I could have a "stack of stacks" to indicate to reviewers where the boundaries between dependent-but-conceptually-distinct features are lol.)

[xremming]

Using gh pr submit and then gh stack sync won't (usually) sync the PRs correctly. It pretty much always causes the already created PR to stay as its own when I'd expect the gh stack sync to essentially adopt it. Sometimes it does work, not quite sure what's required for it.

The web UI allows you to adopt the PR to the stack which fixes the issue but is otherwise annoying (I'd prefer to stay on the command line).

Currently my workflow is like this because Claude knows how to create and write PRs well with gh but it doesn't yet properly understand the gh stack command.

[Anne-alysis]

Allow bypass actors to merge a stack

I'm the only regular reviewer on a small team. Our default branch requires one code-owner approval, and my team is on the branch protection bypass list, so I can merge any single pull request without an approval by ticking "Merge without waiting for requirements to be met".

Once the PRs are linked into a stack, that bypass option is gone, both in the web UI and in gh stack merge ("Bypassing merge requirements is not supported for stacks"). Since an author can't approve their own PRs, I can't merge my own stack at all, even though I could merge each PR on its own.

Workaround today: unstack, merge each PR with the bypass, then rebase the rest with gh stack rebase / gh stack push. Or never link the stack on GitHub. Both lose the stack view and the automatic rebase after a merge.

Request: let actors who can bypass the merge requirements on the base branch merge a stack (or part of one) the same way they can merge a single PR, with the same bypass checkbox and an audit entry per PR.

[comatory]

Is there a way to run gh stack rebase --downstack without fetching the remote? I know it's probably doing regular git rebase under the hood but I would appreciate if I could avoid force pushing when a given PR is under a review.

[DamienCassou]

It would be nice to be able to get a list of stacks as JSON in the same spirit gh stack view --json works for branches. This would allow people to integrate within non-CLI tooling.

[illo-abdulrahim]

Big pain point: rebasing a PR below (e.g fixing a conflict) dismisses all PR review approvals above, that's hella annonying

[comatory]

That isn't a feature of stacked pull requests. I believe you need to adjust your repository's settings to not do that. I believe there's a setting to dismiss reviews when new code arrives.

[jheffernan-il]

Is there a place where we can find out what bugs have been fixed? Would love to turn back on "Automatically delete branches" once this issue is addressed.

[hmrguez]

gh stack rebase and gh stack sync work always via cascade-rebase. Can we add a config or flag like --merge so that gh stack rebase works with incrementally merging the lower branches of the stack into the top branches? That way we get only 1 commit for the merge instead of rewriting the entire git history which makes reviewing new changes painful

[DamienCassou]

If reviewing is painful when you use rebase, I would suggest changing the reviewing tool instead of adding merge commits to your git history. We use https://reviewable.io/ which perfectly handles rebases but there are probably other similar tools.

[bewuethr]

reviewDecision of an upper layer flips to REVIEW_REQUIRED when the stack is merged

After a successful one-click stack merge, the upper PR reports reviewDecision: REVIEW_REQUIRED, even though it was APPROVED/CLEAN right before the merge and its approval was never dismissed. This breaks tools that audit merged PRs via reviewDecision.

Stack base ruleset (pull_request rule):

• required_approving_review_count: 1
• dismiss_stale_reviews_on_push: true
• require_last_push_approval: true
• require_extra_approval_for_unattributed_changes: true
• require_code_owner_review: false

Repro

1. Create two branches with one commit each, and link them: gh stack link --base <base> layer-1 layer-2
2. A second user approves both PRs on their head commits. Both report reviewDecision: APPROVED and mergeStateStatus: CLEAN.
3. Merge the whole stack in one action (squash). The base branch gets a single pr_merge push.

Result (gh pr view --json reviewDecision,mergeStateStatus,headRefOid,reviews)

PR	Before merge	After merge
bottom	APPROVED / CLEAN	APPROVED
top	APPROVED / CLEAN	REVIEW_REQUIRED / DIRTY

The top PR's review is still APPROVED on the unchanged headRefOid. We first saw this on a real three-PR stack, where both upper layers ended up REVIEW_REQUIRED.

Expected: a PR that was approved when it merged keeps reviewDecision: APPROVED.

Possibly the same mechanism as https://github.com/orgs/community/discussions/201439#discussioncomment-17907389 and https://github.com/orgs/community/discussions/201439#discussioncomment-17911023, but here the merge succeeds and only the reported state afterwards is wrong.

[drew-council]

Been loving this tool so far! Massively helpful for tracking discretely reviewable parts of a large change.

I have some minor points of feedback that impact my work daily with this tool:

• The limitations for one operation at a time across worktrees comes up fairly frequently (seems like there's already an issue tracking A paused rebase/sync/modify in one worktree blocks every stack mutation in all other worktrees, even on unrelated stacks github/gh-stack#570)
• I wish there was a really clear "pull from remote state" operation. Maybe a gh stack pull? Sometimes, I actively do not want to rebase my changes onto main (to keep commits the same or to avoid triggering CI), but I do want to get the latest state from remote. This happens often when switching between machines I'm developing on.

[markatlish]

Really surprised there's no gh stack view <STACK_NUMBER> -- my agent needs it, since if it's not on the current stack, it has to infer the state stacks I refer to.