You open a pull request.
87 files changed.
3,500 lines added.
Multiple features mixed together.
Then the reviewer says:
“Can you split this PR?”
We've all been there.
We've all been there.
Large pull requests aren't necessarily bad code. But they're often hard code to review.
That's where stacked PRs can help.
Instead of putting an entire feature into one giant PR, you break the work into small, dependent pull requests.
The result?
Smaller diffs. Easier reviews. Faster feedback.
What Are Stacked PRs?
A stacked PR workflow is a Git workflow where each branch builds on top of another branch.
Instead of:
main
│
└── huge-feature
├── API
├── UI
├── state
├── validation
└── tests
You create a sequence:
main
│
└── feature-base
│
└── feature-api
│
└── feature-ui
│
└── feature-tests
Each branch represents a logical change.
Each branch can have its own pull request.
For example:
PR #1
feature-base → main
PR #2
feature-api → feature-base
PR #3
feature-ui → feature-api
PR #4
feature-tests → feature-ui
The PRs form a stack.
Why Are Giant PRs a Problem?
Imagine you're reviewing this:
1,800 lines changed
74 files changed
23 commits
The reviewer has to understand:
- what changed
- why it changed
- which changes depend on each other
- whether the implementation is correct
- whether anything unrelated slipped in
That's a lot of cognitive load.
And when reviews become difficult, developers often see:
- slower approvals
- more review comments
- missed bugs
- larger merge conflicts
- longer feedback cycles
The problem isn't always the amount of code.
It's the amount of context the reviewer has to hold at once.
A Simple Example
Suppose you're building a new dashboard.
You need to add:
- reusable dashboard components
- API integration
- state management
- page integration
- tests
A traditional workflow might look like:
main
↓
dashboard-feature
Everything goes into one PR.
Instead, you can stack the changes.
Stack 1 — Components
main
↓
dashboard-components
PR:
Add reusable dashboard components
Stack 2 — API
dashboard-components
↓
dashboard-api
PR:
Add dashboard API integration
Stack 3 — State
dashboard-api
↓
dashboard-state
PR:
Add dashboard state management
Stack 4 — Page
dashboard-state
↓
dashboard-page
PR:
Connect dashboard page
Stack 5 — Tests
dashboard-page
↓
dashboard-tests
PR:
Add dashboard tests
Now every PR has a much clearer purpose.
Why Smaller PRs Are Easier to Review
Compare these two approaches.
One giant PR
PR #100
60 files
3,000 lines
5 features
versus:
Stacked PRs
PR #101 → 8 files
PR #102 → 12 files
PR #103 → 10 files
PR #104 → 7 files
The total amount of code might be almost identical.
But each individual review is much easier.
The reviewer can focus on one question:
Is this specific change correct?
How the Git Workflow Works
Let's say you start with main.
Create your first branch:
git checkout main
git pull
git checkout -b feature/base
Make your changes:
git add .
git commit -m "Add dashboard foundation"
git push -u origin feature/base
Create:
feature/base → main
Now create the next branch from feature/base:
git checkout feature/base
git checkout -b feature/api
Make your API changes:
git add .
git commit -m "Add dashboard API"
git push -u origin feature/api
Now create:
feature/api → feature/base
Continue:
main
↓
feature/base
↓
feature/api
↓
feature/ui
Each branch contains the changes from the branches before it.
What Happens When the First PR Merges?
This is where stacked PRs require some discipline.
Initially:
main
↓
A
↓
B
↓
C
PR A is:
A → main
PR B is:
B → A
PR C is:
C → B
After A is merged:
main
↓
A
↓
B
↓
C
B should now eventually target main.
You may need to update/rebase the dependent branches and change the PR base accordingly.
This is one reason stacked workflows work best when the team understands Git well.
Stacked PRs Don't Mean Tiny PRs
There's an important distinction.
The goal isn't:
“Every PR must contain only 50 lines.”
The goal is:
Every PR should represent one logical, reviewable change.
For example, this can be a good PR:
Add authentication service
Even if it changes 15 files.
But this can be a bad PR:
Authentication
- dashboard
- dependency upgrade
- unrelated refactoring
- formatting changes
Even if the total diff isn't huge.
Stacked PRs and Draft Pull Requests
Draft PRs can make stacked workflows even easier.
You can open a PR while the work is still in progress.
For example:
PR #101
Add dashboard components
Then create:
PR #102
Add dashboard API
Reviewers can already see the direction of the work.
Once a PR is ready, you can mark it as ready for review.
This gives the team visibility earlier instead of waiting until the entire feature is finished.
The Biggest Advantage: Faster Feedback
Consider a normal workflow.
You spend two weeks building a feature.
Then you create one PR.
The reviewer finds a fundamental architectural issue.
Now you have to rewrite a large portion of the feature.
With stacked PRs, feedback can happen much earlier.
Foundation
↓
Review
↓
API
↓
Review
↓
UI
↓
Review
You don't wait until the end to discover that the foundation was wrong.
Stacked PRs Can Also Reduce Merge Conflicts
Large branches live for a long time.
The longer a branch stays away from main, the more likely it is to diverge.
That can lead to:
main
↘
feature
↘
merge conflict
Smaller, incremental changes can make integration easier.
But stacked PRs do not automatically eliminate merge conflicts.
If multiple developers modify the same code, conflicts can still happen.
Where Stacked PRs Work Really Well
Stacked PRs are particularly useful for:
_Large features
_
database
↓
API
↓
business logic
↓
UI
↓
tests
_Refactoring
_
Break a large refactor into safe, reviewable steps.
_Platform changes
_
For example:
shared component
↓
migration
↓
feature adoption
_Large frontend applications
_
Especially when different layers can be changed independently.
When You Shouldn't Use Stacked PRs
Don't use them just because they're trendy.
For a small bug fix:
main
↓
fix/login-button
One PR is perfectly fine.
Stacking can add unnecessary complexity when:
- the change is tiny
- branches aren't dependent
- the team isn't comfortable with rebasing
- the stack becomes too deep
- changes are constantly being rewritten
Sometimes a normal PR is simply better.
Common Mistakes
❌ 1. Making the Stack Too Deep
Avoid:
A
↓
B
↓
C
↓
D
↓
E
↓
F
↓
G
A deep stack becomes difficult to maintain.
Keep the dependency chain understandable.
❌ 2. Mixing Unrelated Work
Don't create:
PR 1 → Authentication
PR 2 → Dashboard
PR 3 → Random refactor
PR 4 → Dependency upgrade
These aren't necessarily one stack.
Keep the stack focused around a logical piece of work.
❌ 3. Hiding Dependencies
A reviewer shouldn't have to guess:
“Why can't I merge this PR?”
Make the dependency clear in the PR description.
For example:
Depends on #101
❌ 4. Changing the Base Without Understanding the Stack
Changing a PR's base branch changes the diff the reviewer sees.
If you have:
A → B → C
and suddenly change C directly to main, the PR may show a much larger diff than expected.
Understand the stack before changing its structure.
Stacked PRs vs One Big PR
One Big PR Stacked PRs
Review size Large Smaller
Feedback Often later Earlier
Context High Lower per PR
Dependencies Simple More complex
Git management Easier Requires more discipline
Large features Can become difficult Often a good fit
Small fixes Great Usually unnecessary
The Mental Model
Don't think:
“I need to finish the entire feature before anyone reviews it.”
Think:
“What is the smallest logical change that can be reviewed independently?”
That's the foundation of stacked PRs.
Is Stacked PR the Future of Code Review?
Not necessarily for every team.
But as codebases become larger and development becomes more parallel, reviewable changes matter more than ever.
AI coding assistants are also making it easier to generate large amounts of code quickly.
That creates another problem:
More generated code can mean larger PRs.
A disciplined workflow becomes even more important.
Instead of asking AI to generate an entire feature and opening one massive PR, you can break the implementation into smaller changes:
Architecture
↓
Data layer
↓
API
↓
UI
↓
Tests
Each stage can be reviewed independently.
Final Takeaway
A giant PR isn't automatically bad.
But a giant PR forces reviewers to understand too much at once.
Stacked PRs change the workflow:
One huge change
↓
Many logical changes
↓
Smaller PRs
↓
Earlier feedback
↓
Easier reviews
The goal isn't to write less code.
It's to make the code easier to understand, review, and merge.
Don't make your reviewer understand the whole feature at once. Give them one logical change at a time.
That's the real power of stacked PRs.
