GitHub’s new stacked pull requests feature lets developers create a linear chain of dependent PRs, review each layer separately, and in many cases land the whole stack together. The point is not a new version-control primitive. It is GitHub finally admitting that its normal PR UI is a bad fit for multi-step changes that depend on each other, like “refactor first, feature second, cleanup third.” People who already use Graphite, gh-stack, Gerrit, Phabricator, or Jujutsu recognized the workflow immediately. For them, this is native support for something they have been faking with branch targets, custom tools, or external review systems for years.
The strongest positive case was practical, not ideological. Stacks keep review units small, let different reviewers sign off on different parts of a feature, and avoid the all-or-nothing problem of one large PR where the fifth change blocks the first four. Several commenters said the real gain is not that Git becomes more powerful. It is that GitHub finally gives first-class structure to a workflow the platform previously made awkward, especially when authors needed to keep working before the first PR merged.
The excitement was tempered by a lot of skepticism about the implementation. Early users said the web UI is still thin, the merge path has real bugs, and squash-merge plus required approvals is still painful enough to erase much of the benefit. GitHub confirmed that stacked merges are hard because mergeability, rule checks, and review approvals have to be recomputed against synthetic squashed commits, especially deeper in the stack. Cross-fork support is also missing for now, which sharply limits usefulness for public repositories. The consensus landing point was clear: the workflow itself is valuable and overdue, but this preview looks more like GitHub catching up to established tooling than redefining code review. People who wanted GitHub to use this launch to fix review at the commit or diff-version level came away unimpressed.
If your teams already struggle with giant PRs or long review pipelines, this is worth piloting now, but only with teams that already understand rebasing and branch hygiene. Do not assume native support means the workflow is mature enough for strict review policies, cross-fork open source work, or heavily automated merge queues without extra validation.
Mostly positive about the workflow, but cautious to negative about GitHub’s implementation quality. People like native support for a long-missing review pattern, yet many see the preview as buggy, UI-light, and still constrained by GitHub’s underlying PR model.
Key insights
01
Small dependent changes unblock review
Breaking a feature into dependent layers makes review and merge decisions less coupled. A refactor, a feature built on that refactor, and optional cleanup can each move at their own pace, so an issue in the top layer does not force the base work to sit idle. That is the concrete advantage over one clean PR with many commits. GitHub can already show commits, but it cannot cleanly approve, discuss, and land only the good subset.
Use stacks for changes where early layers are independently valuable and likely to clear review first. If every layer only makes sense as one atomic ship, keep it as one PR and review it together.
The biggest design complaint is that GitHub kept the PR as the review atom instead of building proper diff-version review. That leaves missing pieces people expect from Gerrit, Phabricator, and mailing-list patch flows, like interdiffs, stable change IDs, and rich history across rebases. The current feature mostly wraps a known branch-on-branch workflow in native UI and APIs. It does not modernize the underlying review model.
If your team depends on amend-and-rebase review with durable review history, this will not replace Gerrit-style tooling. Treat it as a workflow convenience layer, not a new review system.
GitHub quietly shipped stack APIs and an async merge API that can land multiple PRs in one atomic operation. That matters because the obvious naive flow, merge one PR, rebase the rest, rerun CI, then repeat, is too expensive for serious repos. With stack-aware queue integration, teams can test and land several layers together and trigger build or deploy once on the final combined push. That turns stacks from a developer convenience into something infrastructure teams can actually support.
If you run a custom merge queue, evaluate the new stack APIs before dismissing the feature as a pure UI change. The operational payoff is in reducing repeated CI and deployment churn across dependent PRs.
The missing cross-fork story is a bigger gap than it sounds. Internal teams working in one repository can adopt stacks now, but public projects often depend on fork-based contribution flows. GitHub says single-fork-contained stacks are coming, while multi-fork stacks are likely blocked by security concerns around automatic rebasing. That means the feature currently fits company repos much better than open source collaboration.
If your project relies on outside contributors working from forks, do not redesign your contribution flow around stacks yet. Wait for fork support details and test how auto-rebase interacts with your security model.
People who liked the feature most often praised the command-line workflow more than the website. gh stack rebase already solves a painful part of maintaining dependent branches, and commenters compared it favorably with Jujutsu features like automatic descendant rebasing and jj absorb. The web UI today mostly exposes relationships that serious users are still managing locally with better tools.
Expect daily stack maintenance to stay in the CLI or local tooling for now. Train developers on rebasing and restacking before rolling this out broadly through the web UI alone.
Splitting one feature into several PRs does not magically reduce the need to reason about the combined result. If the reviewer ultimately has to understand B on top of A and judge whether the merged outcome is sound, the cognitive load may not fall much at all. In cases where later layers depend tightly on earlier ones, separate approvals can create false confidence instead of cleaner review.
Do not assume smaller diffs automatically mean easier review. Ask whether reviewers can meaningfully evaluate each layer in isolation or whether the real object under review is still the whole integrated feature.
Several commenters saw stacked PRs as a workaround for teams that should instead write smaller changes, improve review speed, or simplify architecture. In that view, the tool shifts complexity from developer discipline into platform mechanics and adds another fragile workflow on top of rebases, branches, and protection rules. If the team already struggles with change hygiene, stacks may just produce a more complicated mess.
Pilot stacks only after you have basic review discipline in place. They amplify a good workflow, but they will not rescue a team that already ships tangled, poorly scoped changes.
Early hands-on reports were not about edge polish. They hit the central selling point. Whole-stack merging fails in some common cases, squash merges can force re-approval at every layer, and one bug left a PR stuck in a permanent merging state after a branch delete. For teams with required reviews and strict branch rules, that is enough to make the feature feel half-finished.
Before adopting this in a production repo, test your exact merge policy, especially squash merge, required approvals, and branch deletion behavior. The happy path is not enough if your compliance rules sit on the unhappy path.
github.blog