Stacked PRs will save your reviewers from hating your 3

A 50-file pull request is basically a "LGTM" waiting to happen because nobody actually has the mental bandwidth to audit that much code. We've all been there—you spend a week building a feature, submit one massive PR, and it sits there for three days because the reviewer is terrified to start. Then they ask you to "split it up," and you have to spend another afternoon untangling your own commits.

The fix is moving to a stacked PR workflow. Instead of one giant monolith, you break the work into a sequence of small, dependent branches. You're still writing the same amount of code, but you're delivering it in digestible chunks.

How the stacking actually works

In a standard flow, everything branches off main. In a stacked flow, each branch builds on the one before it. It looks like a chain rather than a star:

main → feature-base → feature-api → feature-ui → feature-tests

Each link in that chain is its own PR. PR #1 targets main, PR #2 targets feature-base, and so on. The reviewer only has to look at the delta between the current branch and its parent, which keeps the cognitive load low.

A real-world scenario

If I'm building a new dashboard, I don't dump the components, the API calls, the state logic, and the tests into one go. I stack them:

• Stack 1: Reusable UI components (Targets main)
• Stack 2: API integration (Targets Stack 1)
• Stack 3: State management (Targets Stack 2)
• Stack 4: Final page assembly (Targets Stack 3)
• Stack 5: Test coverage (Targets Stack 4)

The total lines of code are identical, but the review process is night and day. The reviewer can validate the UI components in five minutes, approve them, and move to the API logic without wondering if a random CSS change on line 400 is related to a bug in the data fetch on line 2,000.

The Git mechanics

This is a practical tutorial on how to actually execute this in your terminal.

1. Start your base:

git checkout main
git pull
git checkout -b feature/base
# ... make changes ...
git add .
git commit -m "Add dashboard foundation"
git push -u origin feature/base

Now open PR: feature/base → main

2. Build the next layer:

git checkout feature/base
git checkout -b feature/api
# ... make changes ...
git add .
git commit -m "Add dashboard API"
git push -u origin feature/api

Now open PR: feature/api → feature/base

The "Merge Headache"

The only real gotcha is when the first PR gets merged. Once feature/base hits main, your feature/api branch is still technically targeting a branch that no longer exists (or is now merged).

You'll need to rebase your dependent branches onto main and update the base of your PRs in GitHub/GitLab. It takes a bit of discipline, but it's a small price to pay for avoiding the "giant PR" dread. If you're using an AI workflow with tools like Claude Code, you can actually have the agent help you identify logical break points in your code to determine where to split your branches before you even start coding.