GitHub Introduces Native Stacked Pull Requests to Streamline Code Review

GitHub has entered the stacked pull request space with the launch of gh-stack, a new CLI extension designed to solve the persistent problem of large, complex pull requests that are difficult to review, slow to merge, and prone to conflicts. This native implementation brings a workflow pattern that has been used internally at companies like Meta and Google for nearly a decade to the broader GitHub ecosystem.

Understanding Stacked Pull Requests

Stacked pull requests, also known as dependent or chained PRs, represent a code-review pattern where each branch in a series targets not the main branch but the branch immediately below it. This approach allows developers to continue work on later layers of a feature while earlier layers are still under review, maintaining a logical progression of changes.

The value proposition is rooted in empirical data. 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 optimal range even when the underlying feature is substantial.

"I was spending a lot of time waiting for code review to happen, which was a major motivator for building the tool," said Evan Priestley, co-creator of Phabricator Differential Research, in the GitHub launch announcement.

Technical Implementation

The gh-stack extension integrates with the existing GitHub CLI and automates 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.

Key features include:

• A stack map in the GitHub pull request interface that allows reviewers to navigate between layers
• Branch protection rules enforced against the final target branch rather than the immediate base of each PR
• CI integration that runs as if each PR were targeting the main branch directly
• AI agent integration for creating and managing stacks

"The CLI is completely optional, you can create stacked PRs purely via the UI," stated Sameen Karim from GitHub.

Historical Context and Existing Solutions

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 as early as 2021 that the approach was applicable to GitHub, though it required care around merge strategy.

A persistent technical challenge remains: squash and rebase merges both rewrite commit hashes, breaking the identity tracking that links branches in a stack. The restriction 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.

As Alan West noted on dev.to, "When you rebase the first branch, every downstream branch needs to be rebased too, manually." West describes a chain of five steps developers must repeat each time a reviewer requests a change on an early PR, suggesting that three to four PRs is a practical ceiling for a stack.

Competitive Landscape

The main competitor to GitHub's offering is Graphite, founded by former Meta engineers, which recently became available without a waitlist. Graphite offers a stack-aware merge queue, 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."

GitHub's entry into stacked PRs offers one key advantage over third-party tools: 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.

Community Reaction and Concerns

Community reaction to the GitHub announcement has been mixed. The Hacker News thread on the launch reached 516 points and 282 comments, revealing several perspectives:

One strand welcomed the move as mainstream validation of a pattern that had been the preserve of large engineering organizations: "Stacked diffs have existed at Meta for a decade, glad GitHub is joining 2016."

A sceptical strand questioned whether the workflow makes sense 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, summarized by ByteIota, pointed to squash-merge compatibility and cascading rebase conflicts as unresolved technical problems that Graphite has had years to work through.

Business Impact and Adoption Considerations

For organizations considering adoption, the business impact of stacked PRs extends beyond code review efficiency. The approach can significantly reduce merge conflicts, decrease time-to-merge for complex features, and improve code quality through smaller, more focused changes.

However, successful implementation requires careful consideration of team dynamics and workflow integration. Teams must establish clear guidelines for what constitutes a logical layer in a stack, how to handle dependencies between PRs, and when to use stacked PRs versus traditional approaches.

The learning curve represents another consideration. While the CLI automates many aspects of managing stacked PRs, team members still need to understand the underlying concepts and potential pitfalls.

Current Status and Future Outlook

The feature entered private preview on 13 April 2026, and developers must join a waitlist before the extension will function for their repository. GitHub's 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 introduction of stacked PRs represents GitHub's recognition of evolving code review needs in an era of increasingly complex features and distributed teams. As the feature matures, it may become a standard approach for managing substantial changes across the GitHub ecosystem.