GitHub's stacked pull requests are now in public preview — a workflow shift that could change how engineering teams handle large, dependent code changes. Here's what it means in practice.

Stacked Pull Requests on GitHub: What They Are and Why They Matter

Most engineers have been there: you're working on a large feature that naturally breaks into several logical steps. Step B depends on Step A, Step C depends on Step B — and suddenly you're staring at a monolithic pull request that no reviewer wants to touch, or you're manually juggling branches and rebasing until something breaks.

GitHub's public preview of stacked pull requests is a direct answer to that pain point. It formalizes a workflow that high-output engineering teams have been hacking together with third-party tools for years.

What "Stacked PRs" Actually Means

A stacked pull request is one that targets another open pull request as its base, rather than targeting main or develop directly. You build a chain — or a stack — of PRs, where each one represents an incremental, reviewable unit of work.

main
 └── PR #1: Add database schema for payments
      └── PR #2: Build payment processing service
           └── PR #3: Add payment UI components

Each PR in the stack is independently reviewable. A teammate can approve and merge PR #1 without waiting for the entire feature to be complete. When PR #1 merges, GitHub can now automatically re-target PR #2 to point at main, collapsing the stack gracefully.

That last part — automatic re-targeting — is what makes the native GitHub implementation genuinely useful. Without it, stacked PRs are a manual rebase nightmare.

Why Teams Avoided This Before

The concept of stacking PRs is not new. Tools like Graphite, Aviator, and even the gh CLI with custom scripts have offered stacked workflow support for a while. The problem was always friction:

Developers had to use an external tool or remember a specific CLI sequence.
When a base PR was merged, updating all downstream branches required manual intervention or a paid service.
GitHub's own UI had no awareness of the stack, so reviewers saw confusing diffs that included changes from parent PRs.

That last issue is the most underrated. If PR #2 is based on PR #1, and you open PR #2 on GitHub without stacking support, the diff shows all of the changes from both PRs lumped together. Reviewers have no clean way to see only what PR #2 introduces. Native support fixes this by scoping the diff correctly to each layer.

What Changes for Engineering Teams

For teams shipping custom software or SaaS products under tight deadlines, this workflow shift has a few concrete implications.

Faster review cycles. Instead of waiting for an entire feature branch to be "done enough" to review, teammates can start reviewing early layers of a stack while later layers are still being written. Parallel review unlocks genuine velocity gains.

Cleaner commit history. Stacked PRs naturally encourage smaller, more focused commits. Each PR in a stack should tell a coherent story on its own — which means your Git history becomes a readable changelog rather than a dump of wip commits.

Better separation of concerns. When you force yourself to stack logically, you often catch architectural shortcuts early. If you can't cleanly describe what PR #2 does without referencing PR #1's internals, that's a signal your layers aren't properly decoupled.

Reduced merge conflicts. Because each stack layer is merged incrementally and quickly, the long-lived feature branches that accumulate drift from main — and the painful merge conflicts they produce — become less common.

Practical Considerations Before You Adopt It

Stacked PRs are powerful, but they introduce coordination overhead that teams should think through before rolling them out universally.

Stack depth matters. A stack of 2–3 PRs is usually manageable. Stacks of 7–8 layers introduce significant mental overhead for reviewers and increase the risk of mid-stack changes cascading downward.
Communication is non-negotiable. Reviewers need to understand the stack order. GitHub's UI will help here, but teams should still document the intended merge sequence in PR descriptions.
CI costs can multiply. Each PR in a stack runs its own CI pipeline. On large stacks, this can increase compute costs and queue time. Teams using GitHub Actions should audit their workflow triggers before adopting stacking at scale.
Not every feature needs a stack. Small, self-contained changes should still go straight to main. Stacking is a tool for complexity, not a default workflow.

How to Start Using It Today

As of the public preview, stacked PRs are available on GitHub.com. To create a stack, you create a new branch off an existing feature branch (not main), push your changes, and open a PR targeting that feature branch. GitHub will recognize the relationship and display the stack visually in the PR interface.

The automatic re-targeting behavior — where GitHub updates downstream base branches after a merge — is the feature to watch most closely during the preview period. Its reliability under real-world team conditions will determine whether this replaces third-party stacking tools or merely supplements them.

Why This Matters for Your Project

If you are building or scaling a software product — whether that is a SaaS platform, a mobile application, or an internal enterprise tool — your team's PR hygiene has a direct impact on delivery speed and code quality. Native stacked PRs lower the barrier to incremental, reviewable development without requiring external tooling or workflow gymnastics. For engineering teams that have been defaulting to large, high-risk PRs simply because the tooling made small ones inconvenient, this is a meaningful shift worth adopting deliberately.

Source: GitHub Changelog — Stacked Pull Requests are now in Public Preview