Imagine this—you just finished a massive feature. Hundreds of lines of code across dozens of files. You changed the database, the frontend, and the server logic. You finally submit the huge pull request (PR) for review and... you're blocked. You can’t move on to the next critical task until this mega PR gets reviewed and merged.
So you're stuck with two bad options:
1. Switch to a low-priority task from the backlog, stalling momentum.
2. Repeatedly ping your coworkers, begging for a faster review.
This isn’t a hypothetical problem; it’s the reality for teams stuck with monolithic pull requests. But there’s a better way. The best engineering teams at companies like Meta have used stacked PRs for years to accelerate their development. Stacking unblocks you by splitting large changes into small, manageable PRs that you can build on top of each other.
Once you experience an unblocked workflow, you'll never go back. Let's dig into how stacking works and why it’s the new standard for high-performance teams.
What is stacking, and how does it work?
Stacked pull requests are like building with LEGOs. You start with a solid foundation—the main branch. On top of this, you add your first piece: a small, focused code change. While that first piece is being reviewed, you can start adding the second. Each piece builds on the last, allowing you to construct something complex without waiting for approval at every step.
That’s the core idea of stacking: break large features into a series of tiny, dependent pull requests. Each small PR can be tested, reviewed, and merged independently, completely unblocking you from the code review process.
To put things in perspective, let’s take an example of an e-commerce checkout flow. Instead of a single large PR with hundreds of lines of code, you can break the checkout flow into several smaller PRs:
PR 1: Add the checkout button UI.
PR 2: Build the checkout form fields.
PR 3: Integrate the payment gateway.
PR 4: Handle order submission and completion
You can work on each component without waiting for reviews. PR 2 is branched off PR 1, PR 3 is branched off PR 2, and so on. This eliminates the need to wait for code to merge to main before you can build the next part of the feature.
Because the PRs are small, reviews are faster and more thorough. This gets your code merged with fewer bugs and less delay.
Why you can’t go back: the benefits of stacking
Adopting a stacked PR workflow provides key advantages that let you ship faster. Once you experience these benefits, the old way of doing things feels impossibly slow.
Fully unblocked dev workflows
With a stacked PR workflow, you open your first PR with a small change, submit it for review, and immediately start the next branch on top of it. This approach eliminates development bottlenecks and ensures an uninterrupted workflow. You stay focused on building, not waiting.
For our e-commerce example:
Your first PR implements just the checkout button.
The next PR builds the form elements.
The third handles order processing.
At each step, you continue building without waiting for approvals. You’re no longer blocked for hours or days on a 1,000-line PR.
Easier debugging
Debugging is simpler when you isolate changes. If your giant, all-in-one PR breaks the payment gateway, good luck digging through hundreds of edits across 20 files to find the cause.
With stacked PRs, any issue is almost certainly in the last small change you made. Since each PR is under 200 lines, it's easy to find what went wrong and revert it. Instead of one huge change that breaks your entire checkout flow, you have small, incremental components that make identifying and fixing issues simple.
Quicker, more thorough reviews
Let's be honest: nobody wants to review a 1,000-line pull request. They often get delayed or rubber-stamped.
With stacking, reviews become focused and efficient. Reviewers can easily understand the scope when a PR touches five files instead of 50, leading to faster and higher-quality feedback. In a stacked world, you'd have a separate PR for the checkout button, the form UI, and the order processing logic—each is much simpler to digest, which cuts down the overall review time.
How to implement the stacking workflow for your team
Moving to a stacked workflow can be a change, but once your team gets the hang of it, the productivity gains are significant. Developers stay focused on writing code, not waiting for reviews.
The transition requires some teamwork. Here's how to start:
1. Assess your team's trunk-based development maturity: Ensure developers are comfortable with concepts like rebasing, short-lived branches, and rapid integration.
2. Get buy-in by communicating benefits: Show how stacking solves real pain points like review delays and merge conflicts.
3. Define team-wide standards: Align on expectations for PR size (<200 lines of code) and review turnaround times (<24 hours).
Integrating a tool built for stacking can make the transition much faster. Graphite helps your team create and manage stacks from the command line while automating the complexity behind the scenes.
Stacking workflow with GitHub vs Graphite
While you can technically stack PRs with just GitHub, the workflow is manual and error-prone. To see the difference, let's build a "dark mode" feature broken into a parent PR and two dependent children.
The GitHub workflow (the hard way)
First, create the initial parent PR:
// Start point is main branch
git checkout -b dark-mode-toggle
// Implement toggle UI component, then add the file.
git add DarkModeToggle.js
git commit -m "Feature: Add dark mode toggle UI"
// Creates PR
git push -u origin dark-mode-toggle
Next, you stack two child PRs on top, one for styles and one for transitions.
// Checkout the parent PR
git checkout dark-mode-toggle
// Create the child PR
git checkout -b dark-mode-styles
// Implement the dark mode styles and styling elements
git add DarkModeStyles.css
git commit -m "Feature: Styling dark mode"
git push origin dark-mode-styles
// Create second child PR
// while you’re checked out on dark-mode-styles (first child)
git checkout -b dark-mode-transitions
// Implement the transitions
git add DarkModeTransitions.js
git commit -m "Feature: Add theme transitions"
git push origin dark-mode-transitions
This manual process creates immediate problems. If a reviewer requests a change on the parent branch (`dark-mode-toggle`), you have to manually rebase every single child branch to propagate the update.
// Checkout the parent branch
git checkout dark-mode-toggle
// Reviewer comments on the parent branch
// You make changes and push code to the parent branch
git add DarkModeToggle.js
git commit -am "BugFix: Fix padding based on feedback"
git push origin dark-mode-toggle
// You now need to make upstream changes
// Manually rebase child branches on updated parent
git checkout dark-mode-styles
git rebase dark-mode-toggle
// Rebase the second child and continue doing so for all branches
git checkout dark-mode-transitions
git rebase dark-mode-styles
The GitHub workflow is tedious. You're responsible for:
Constant, manual rebasing.
Resolving merge conflicts across a long chain of branches.
Manually tracking all the dependencies.
This overhead distracts from writing code. Now let's see how Graphite automates this.
Stacking PRs with Graphite
With the Graphite CLI, you just create branches and let it manage the dependencies. After installing it and navigating to your repo, you can create your first branch.
// Modify your files since the next command will
// create a new branch with your changes off of the branch
// you’re currently at
gt create -am "Feature: Add dark mode toggle UI"
This command creates a new branch and commits your staged changes. To stack the next part of the feature, you just run the command again. Graphite automatically stacks the new branch on top of your current one.
// Make changes while you’re on the toggle UI branch
// Then run the below command to create a new child branch with the changes
gt create -am "Feature: Styling dark mode"
When you need to address feedback on the parent branch, a single `gt modify` command updates the branch and automatically restacks all its children. No manual rebasing is required.
// Checkout the branch that received review comments
// Make changes to the required files and then
// run the following command
$ gt modify -a
[01-04-Feature_Add_dark_mode_toggle_UI f24cf74] Feature: Add dark mode toggle UI
1 file changed, 1 insertion(+)
Restacked 01-04-Feature_Styling_dark_mode on
01-04-Feature_Add_dark_mode_toggle_UI.
Restacked 01-04-Feature_Add_theme_transitions
on 01-04-Feature_Styling_dark_mode.
When you're ready to submit, `gt submit` bundles the entire stack, handles pushing to the remote, and opens all the PRs with the correct dependencies.
$ gt submit
🥞 Validating that this Graphite stack is ready to submit...
✔ How would you like to proceed? > Continue with empty branches
✏️ Preparing to submit PRs for the following branches...
▸ 01-04-Feature_Add_dark_mode_toggle_UI (Create)
✔ Title ... Feature: Add dark mode toggle UI
✔ Body > Skip (leave empty)
✔ Submit > Create Draft Pull Request
▸ 01-04-Feature_Styling_dark_mode (Create)
✔ Title ...
✔ Body > Skip (leave empty)
✔ Submit > Create Draft Pull Request
▸ 01-04-Feature_Add_theme_transitions (Create)
✔ Title ...
✔ Body > Skip (leave empty)
✔ Submit > Create Draft Pull Request
📨 Pushing to remote and creating/updating PRs...
The CLI prints out URLs for the new PRs, and Graphite even allows reviewers to merge dependent branches automatically. The entire process is streamlined.
The difference is clear. GitHub requires you to manually manage every dependency and rebase. Graphite automates the coordination, which lets you focus on your code instead of Git mechanics.
Ready to unblock your team and achieve peak productivity?
Stacked pull requests are a fundamental improvement over monolithic PRs. They unblock developers, improve code quality, and lead to faster innovation. By removing the bottleneck of massive pull requests, your team can achieve a state of flow and productivity.
Ready to leave monolithic PRs behind? Install the CLI and start stacking in minutes.