GitHub has launched a native stacked pull request workflow through a new CLI extension called gh-stack, closing a gap that third-party tools have filled for several years. It aims to resolve the problem where large pull requests are hard to review, slow to merge and prone to conflicts, with GitHub stating that reviewers lose context, feedback quality drops, and the whole team slows down.
Stacked pull requests, sometimes called dependent or chained PRs, are a code-review pattern in which each branch targets not the main branch but the branch immediately below it in a series. The approach lets developers continue work on later layers of a feature while earlier layers are still under review.
"I was spending a lot of time waiting for code review to happen, which was a major motivator for building the tool."
Evan Priestley, co-creator of Phabricator Differential
Research cited in the launch announcement suggests the workflow has measurable benefits. An analysis of 1.5 million pull requests found that PRs between 200 and 400 lines had 40% fewer defects and were approved three times faster than larger ones. The stacked approach is designed to keep individual PRs within that range even when the underlying feature is substantial.
The gh-stack extension integrates with the existing GitHub CLI and handles the mechanics that have historically made stacked workflows painful to maintain manually. The primary command, gh stack sync, cascades a rebase across the entire stack and force-pushes each branch atomically after a change to an earlier layer. GitHub's pull request interface gains a stack map that lets reviewers navigate between layers, and branch protection rules are enforced against the final target branch rather than the immediate base of each PR. CI similarly runs as if each PR were targeting the main branch directly.
The extension also ships with an AI agent integration. Running gh skill install github/gh-stack teaches compatible AI coding agents how to create and manage stacks, allowing them to break a large diff into layers or develop with stacks from the beginning of a task.
"The CLI is completely optional, you can create stacked PRs purely via the UI."
Sameen Karim, GitHub
The stacked diff pattern is not new to software development. Meta and Google both adopted similar workflows nearly a decade ago, building custom tooling, including Phabricator and Gerrit. Simohamed Marhraoui wrote in LogRocket as early as 2021 that the approach was already applicable to GitHub, though it required care around merge strategy: squash and rebase merges both rewrite commit hashes, breaking the identity tracking that links branches in a stack. The restriction Marhraoui noted, that only a standard merge commit should be used for intermediate PRs in a chain, remains a practical concern with any stacked workflow on GitHub.
Alan West, writing on dev.to shortly after the launch, observed that git itself offers no help managing the relationship between dependent branches. "When you rebase the first branch, every downstream branch needs to be rebased too, manually," West wrote, describing a chain of five steps that developers must repeat each time a reviewer requests a change on an early PR. West notes that three to four PRs is a practical ceiling for a stack: "Beyond that, the cognitive overhead of tracking dependencies starts to outweigh the review benefits."
The main competitor to GitHub, Graphite, founded by former Meta engineers, is now available without a waitlist today. Graphite offers a stack-aware merge queue, a web-based review interface, VS Code integration, and a CLI. Its free tier includes the CLI and stacking workflow; paid plans start at $20 per user per month. Joe Buza noted on LinkedIn in February 2026 that he had been prompting AI coding agents to break features into stacked PRs using a Graphite-style workflow, constraining each PR to under 200 lines and requiring that each layer "do one logical thing and make sense on its own."
Community reaction to the GitHub announcement has been mixed. The Hacker News thread on the launch reached 516 points and 282 comments. One strand of the discussion welcomed the move as mainstream validation of a pattern that had been the preserve of large engineering organisations: "Stacked diffs have existed at Meta for a decade, glad GitHub is joining 2016." A sceptical strand questioned whether the workflow makes sense at all on GitHub's infrastructure: "Either changes are independent and you use separate PRs, or they're dependent and reviewing them separately makes no sense." A further line of criticism, summarised by ByteIota, pointed to squash-merge compatibility and cascading rebase conflicts as unresolved technical problems that Graphite has had years to work through.
GitHub's entry into stacked PRs is notable for one feature that third-party tools cannot offer: the stack map and enforcement logic live inside the pull request UI itself, meaning reviewers do not need a separate account or extension to see the context. The official documentation notes that the CLI is "entirely optional" and that stacks can be created through the GitHub UI or API directly. Whether that native integration is enough to attract teams that already use Graphite, or bring the workflow to developers who have never tried stacking at all, will depend largely on how GitHub handles the edge cases during the private preview period.
The feature entered private preview on 13 April 2026, and developers must join a waitlist before the extension will function for their repository. Related coverage on InfoQ includes a February 2026 piece on GitHub's reworked layered defences for infrastructure policy enforcement, and an April 2026 article on Anthropic's agent-based code review for Claude Code, which found that substantive review comments on PRs with more than 1,000 lines changed rose from 16% to 84% after adoption of automated review tooling.