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 has finally become a native part of the GitHub 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 split 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 internal code management practices at 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 on top of 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 branching 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 typically create a feature branch from main, complete their work, and submit a single PR. When a feature is complex, this often produces a "mega PR" with dozens or even hundreds of file changes. These types of 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 merging—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 between 200-400 lines, with defect detection rates dropping significantly beyond 400 lines. Google's 2018 paper Modern Code Review: A Case Study at Google 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 dramatically improved review turnaround 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 "deep review mode," causing the probability of missing critical logic defects to increase several-fold.

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 one logical unit, and the next PR builds on the branch of the previous one rather than directly on main.

For example, implementing a new feature might be split 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 independently reviewed and discussed, while GitHub automatically manages the dependency relationships and merge order between them.

Why Stacked PRs Are Worth Paying Attention To

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 the bottom PR in the stack merges, the upper PRs 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 code regions modified by upper commits conflict with main's latest state, rebase conflicts requiring manual resolution will occur. In multi-layer stacks, conflicts can propagate layer by layer—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 for. How GitHub's native solution handles multi-layer conflict propagation will be an important measure of its maturity.

Lowering the Adoption Barrier

Previously, teams wanting to use a stacked workflow 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—teams can manage stacks directly within the familiar interface.

GitHub Stacked PRs vs. Graphite and Other Solutions

Stacked PRs are not a concept GitHub invented. Meta has long used a stacked workflow based on Mercurial internally and open-sourced Sapling; the startup Graphite built a complete commercial product around this concept and has amassed a loyal 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 view of the stack, allowing reviewers to clearly see each PR's position and context within the stack. 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 notable 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—it's the external version of a version control tool used internally at Meta for over a decade. Unlike Git, Sapling inherits Mercurial's design philosophy—using commits rather than branches as the core unit of work. In Sapling, developers naturally work on a chain of commits, 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, primarily 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 need to switch tools, no extra accounts, no concerns about compatibility with GitHub Actions or branch protection rules. However, in terms of feature maturity, as a public preview product, it likely doesn't yet match the level of polish that specialized tools like Graphite offer in CLI experience, visualization, and automation. For teams heavily reliant on stacked workflows, the trade-offs between the two are worth monitoring over time.

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 writing code;
• Maintain atomicity and reviewability in every commit;
• Transform code review from a "one-time gate" into a "continuous quality assurance process."

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

CI/CD Pipeline Adaptation Challenges

It's worth noting that the introduction of stacked PRs poses new adaptation requirements for teams' existing CI/CD pipelines. In stacked PR scenarios, 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 resource waste from unnecessary redundant builds. Branch Protection Rules also need adaptation—traditional rules require the PR branch to be up-to-date relative to main, but in stacked scenarios, intermediate PRs are based on 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 and more teams to re-examine 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 to evaluate its compatibility with existing CI/CD pipelines and team habits.

Key Takeaways