GitHub Stacked Pull Requests Explained: A New Way to Break Down Large Code Changes

GitHub Launches Stacked Pull Requests

GitHub recently announced that Stacked Pull Requests have officially entered public preview. This long-awaited feature by many developers has finally become part of GitHub's native workflow. Previously, stacked PRs were a core selling point of third-party tools like Graphite and Sapling. Now that GitHub has incorporated this into its own platform, it marks a significant evolution in code collaboration.

For developers who have long collaborated on GitHub, this isn't just a new button—it's an official response to the fundamental question of how large changes should be broken down and reviewed in modern software development.

What Are Stacked PRs?

Industry Origins and Historical Background

The concept of stacked code changes is not a recent invention. Its roots trace back to code management practices within tech giants like Google and Meta. Google's Mondrian (which later evolved into Critique) code review system supported breaking large changes into ordered chains of CLs (changelists) from early on. Meta built internal tools based on the Mercurial version control system that natively supported the concept of "commit stacks," allowing developers to maintain a series of dependent commits locally, with each commit corresponding to an independent code review unit. The core philosophy behind this practice comes from "Differential Development"—the pattern popularized by the Phabricator toolchain—where each diff is an atomic logical change. Git's branch model is naturally suited to this workflow, but GitHub's PR interface has long been branch-centric rather than commit-chain-centric, leaving this pattern without native support in the GitHub ecosystem.

Pain Points of Traditional PR Workflows

In the traditional GitHub workflow, developers create a feature branch from main, complete their development, and submit a single PR. When a feature is complex, it often produces a "mega PR" with dozens or even hundreds of file changes. These PRs have several obvious problems:

• Difficult to review: Reviewers facing hundreds or thousands of lines of code struggle to focus on the logic and easily miss issues.
• Merge blocking: The entire PR must pass review as a whole before it can be merged—any small disagreement holds up all changes.
• Inefficient iteration: If you need to continue developing on top of prerequisite logic, you can only wait for the previous PR to merge or manually manage branch dependencies.

The relationship between code review effectiveness and change size has been well studied in both academia and industry. A classic study by Cisco (SmartBear, 2006) found that code reviews are most effective for changes of 200-400 lines, with defect detection rates dropping significantly beyond 400 lines. In Google's 2018 paper Modern Code Review: A Case Study at Google, they noted that over 35% of their internal code changes are fewer than 10 lines, with a median of around 24 lines—this small-change strategy greatly improved review pass rates and defect capture rates. Microsoft's research team similarly found that when a Pull Request modifies more than 20 files, reviewers tend to adopt a "browsing mode" rather than a "deep review mode," causing the probability of missing critical logic defects to increase several times over.

The Core Idea Behind Stacked PRs

The core idea of stacked PRs is: break a large change into a series of small, independent, interdependent PRs that form a "stack." Each PR focuses on a single logical unit, with the next PR building on the previous PR's branch rather than directly on main.

For example, implementing a new feature might be broken down into:

1. Underlying data model changes (PR #1)
2. Business logic layer implementation (PR #2, based on #1)
3. API endpoint exposure (PR #3, based on #2)
4. Frontend interface integration (PR #4, based on #3)

Each PR can be reviewed and discussed independently, while GitHub automatically manages the dependency relationships and merge order between them.

Why Stacked PRs Deserve Attention

Significantly Improved Code Review Quality

Fine-grained PRs are naturally easier to review thoroughly. Research and engineering practice consistently show that code review effectiveness drops sharply as change size increases. When each PR contains only one or two hundred lines of related changes, reviewers can truly understand the code's intent and provide valuable feedback, rather than mechanically clicking "Approve."

Unlocking Parallel Development

The stacked workflow lets developers continue building subsequent features on top of earlier work without waiting for prerequisite PRs to merge. This is especially important for fast-paced teams—you can keep pushing development forward while review work happens in parallel. When a PR at the bottom of the stack merges, the PRs above it automatically rebase onto the latest main.

Rebase is a core Git operation that essentially "transplants" a series of commits onto a new base point. In the stacked PR scenario, when the bottom PR merges into main, the base point of upper branches becomes outdated and needs to be updated to the latest main branch via rebase. During this process, Git replays each commit's changes sequentially—if the code regions modified by upper commits conflict with main's latest state, rebase conflicts arise that require manual resolution. In multi-layer stacks, conflicts can propagate through layers—the resolution produced by rebasing PR #2 may affect the rebase results of PR #3 and PR #4. This is one of the biggest technical challenges of the stacked workflow and a key area that tools like Graphite optimize. How GitHub's native solution handles multi-layer conflict propagation will be an important measure of its maturity.

Lowering the Adoption Barrier

In the past, teams wanting to use stacked workflows had to adopt external tools like Graphite, Sapling (open-sourced by Meta), or git-branchless, bearing additional learning costs and toolchain maintenance overhead. With GitHub's native support, the adoption barrier for this workflow drops dramatically, and teams can manage stacks directly within the familiar interface.

GitHub Stacked PRs vs. Graphite and Other Solutions

Stacked PRs are not a concept originated by GitHub. Meta has long used Mercurial-based stacked workflows internally and open-sourced Sapling; the startup Graphite built a complete commercial product around this concept, accumulating a large following.

Graphite's Technical Implementation and Product Positioning

Graphite is a developer tools company founded in 2021 by former Meta engineers. Its core product is a CLI tool and web interface built around stacked PRs. Graphite's CLI (gt command) wraps complex Git operations, automatically tracking parent-child relationships between branches, handling rebase conflict propagation, and batch-updating dependency information in PR descriptions. Its web interface provides a visual stack view where reviewers can clearly see each PR's position in the stack and its context. Graphite also offers a "Merge Queue" feature that ensures PRs in a stack merge in the correct order without breaking CI. As of 2024, Graphite has raised over $30 million in funding, with customers including well-known tech companies like Plaid and Ramp. The launch of GitHub's native stacked PRs poses a direct challenge to Graphite's business model.

Sapling and Mercurial's Design Philosophy

Sapling is a source control management client open-sourced by Meta in 2022—an external version of the version control tool Meta used internally for over a decade. Unlike Git, Sapling inherits Mercurial's design philosophy—centering on commits rather than branches as the core work unit. In Sapling, developers naturally work on a commit chain, where each commit can be independently sent for review, independently modified, and independently merged. This design eliminates the complexity of managing multiple interdependent branches in Git. Sapling is compatible with Git repositories and can serve as an alternative Git client, but its adoption in the GitHub ecosystem has been limited, mainly due to its learning curve and friction with GitHub's native workflow.

Comparison Summary

GitHub's biggest advantage in entering this space is native integration—no tool switching, no extra accounts, no worrying about compatibility with GitHub Actions or branch protection rules. However, in terms of feature maturity, as a public preview product, it may not yet match the polish of specialized tools like Graphite in CLI experience, visualization, and automation. For teams heavily dependent on stacked workflows, the tradeoff between the two is worth continued observation.

Impact of Stacked PRs on Developer Workflows

The proliferation of stacked PRs is essentially promoting an engineering culture of "small steps, fast iterations, continuous delivery." It encourages developers to:

• Think about how to decompose large tasks into independently verifiable logical units before starting;
• Maintain atomicity and reviewability in each commit;
• Transform code review from a "one-time gate" into a "continuous quality assurance process."

For individual developers, this workflow may feel cumbersome; but for medium-to-large teams—especially organizations that require frequent collaboration and pursue high-quality codebases—stacked PRs are poised to significantly improve collaboration efficiency and code quality.

CI/CD Adaptation Challenges

It's worth noting that the introduction of stacked PRs poses new adaptation requirements for teams' existing CI/CD pipelines. In the stacked PR scenario, CI faces unique challenges: each PR needs to run tests in the context of its dependency chain, not just against main. When a PR in the stack is modified, all PRs above it may need to re-trigger their CI pipelines. GitHub Actions, as GitHub's native CI platform, needs to correctly identify dependency relationships between PRs and optimize build trigger strategies to avoid unnecessary duplicate builds that waste resources. Branch Protection Rules also need adaptation—traditional rules require PR branches to be up-to-date relative to main, but in stacked scenarios, intermediate PRs have a base branch that is another feature branch rather than main, requiring the semantics of protection rules to be redefined.

Summary and Recommendations

GitHub incorporating stacked PRs as a native feature is an official endorsement of modern software engineering practices. As the feature moves from public preview to general availability, we can expect more teams to reassess their PR splitting strategies. For developers still battling "mega PRs," now is a great time to try this new workflow. Teams interested in adopting it are advised to pilot it on non-critical projects first, evaluating how well it adapts to existing CI/CD pipelines and team habits.

Key Takeaways