Stacked pull requests cut reviewer burnout by splitting work into smaller, focused tasks.

A PR with fifty files becomes a bottleneck, forcing reviewers to spend hours scanning code beyond their mental capacity. The usual pattern plays out: weeks of development culminate in a single massive PR, only to languish for days while the reviewer delays approval, hoping for better clarity. When feedback arrives—like splitting the work—time is wasted refactoring tangled commits.

Instead, a stacked PR approach organizes changes into a series of dependent branches rather than a single monolithic request. The code volume stays the same, but the workflow adapts. Each branch builds on the previous one, creating a linear dependency chain: main → feature-base → feature-api → feature-ui → feature-tests. Each segment becomes its own PR, so PR 1 targets main, PR 2 targets feature-base, and so on. Reviewers focus only on the incremental changes, reducing cognitive strain.

For example, when developing a new dashboard, combining UI components, API calls, state logic, and tests into one PR creates unnecessary complexity. Instead, break it down:

1. Reusable UI components (target main),
2. API integration (targets Stack 1),
3. State management (targets Stack 2),
4. Final page assembly (targets Stack 3),
5. Test coverage (targets Stack 4).

The same lines of code are reviewed in smaller chunks, allowing quick validation of individual components without overlapping concerns.

To begin, start with the base layer:

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

Open PR for feature/base → main. For the next layer:

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

Now open PR for feature/api → feature-base.

The only challenge arises when merging the first PR. After feature/base reaches main, dependent branches like feature/api no longer target an existing branch. To avoid disruption, rebase them onto main and update PR targets in GitHub or GitLab. This step requires discipline, but it’s far preferable to the stress of a “giant PR.” Tools like Claude Code can help preemptively split work by analyzing code logic before development begins.