Skip to content
rung

What are Stacked PRs?

Stacked PRs (pull requests) are a development pattern where you break a large feature into a series of smaller, dependent changes that build on each other.

The Problem with Large PRs

Section titled “The Problem with Large PRs”

Traditional development often results in large pull requests:

main ─────────────────────────────────────────────────────●
                                                          │
                                                          └── my-feature (500 lines changed)

Large PRs have several problems:

  • Hard to review — Reviewers struggle to understand 500+ lines of changes
  • Slow feedback — Reviews take longer, blocking your work
  • Risky merges — More code means more chances for bugs
  • Context switching — You can’t work on other things while waiting

The Solution: Stacked PRs

Section titled “The Solution: Stacked PRs”

Instead of one large PR, create a stack of smaller, focused PRs:

main ─────●
          │
          └── add-user-model (PR #1: 80 lines)
                │
                └── add-user-api (PR #2: 120 lines)
                      │
                      └── add-user-tests (PR #3: 100 lines)

Each PR:

  • Does one thing well
  • Builds on the previous PR
  • Can be reviewed independently
  • Is merged in order (bottom to top)

Benefits

Section titled “Benefits”

1. Faster Reviews

Section titled “1. Faster Reviews”

Small PRs get reviewed faster. A 100-line PR is easy to understand and approve. A 500-line PR sits in the queue.

2. Better Feedback

Section titled “2. Better Feedback”

Reviewers can give more thoughtful feedback on focused changes. They understand the context completely.

3. Safer Merges

Section titled “3. Safer Merges”

Each PR is small and tested. If something breaks, you know exactly where to look.

4. Parallel Work

Section titled “4. Parallel Work”

While PR #1 is being reviewed, you can continue working on PR #2 and #3. Your stack keeps growing, and reviews flow in as they’re ready.

5. Clear History

Section titled “5. Clear History”

Each merged PR represents a logical unit of work. Your git history tells a story.

The Challenge

Section titled “The Challenge”

Stacked PRs are powerful but have a manual overhead:

  1. When main changes, you need to rebase all your branches
  2. When PR #1 is approved, you need to update PR #2’s base branch
  3. Keeping track of which branches depend on which is error-prone

This is where rung helps.

How Rung Helps

Section titled “How Rung Helps”

Rung automates the tedious parts of stacked PRs:

Branch Tracking

Section titled “Branch Tracking”

Rung remembers which branches depend on which:

Terminal window
$ rung status


  Stack
  ──────────────────────────────────────────────────
  ●   add-user-model #41 ← main
  ●   add-user-api #42 ← add-user-model
  ● ▶ add-user-tests #43 ← add-user-api
  ──────────────────────────────────────────────────


  ● synced  ● needs sync  ● conflict

Automatic Rebasing

Section titled “Automatic Rebasing”

When main changes, one command updates everything:

Terminal window
$ rung sync
✓ Synced add-user-model (rebased 3 commits)
✓ Synced add-user-api (rebased 2 commits)
✓ Synced add-user-tests (rebased 1 commit)

PR Management

Section titled “PR Management”

Submit all your PRs with correct base branches:

Terminal window
$ rung submit
✓ Created PR #41: add-user-model (base: main)
✓ Created PR #42: add-user-api (base: add-user-model)
✓ Created PR #43: add-user-tests (base: add-user-api)

Merge Handling

Section titled “Merge Handling”

When you merge, rung updates the remaining stack:

Terminal window
$ rung merge  # On add-user-model
✓ Merged PR #41
✓ Rebased add-user-api onto main
✓ Updated PR #42 base to main

When to Use Stacked PRs

Section titled “When to Use Stacked PRs”

Stacked PRs work best for:

  • Large features that can be broken down logically
  • Refactoring + feature work (refactor first, then feature)
  • Database migrations (migration PR, then code PR)
  • API changes (backend PR, then frontend PR)

When Not to Use Stacked PRs

Section titled “When Not to Use Stacked PRs”

Stacked PRs add complexity. Skip them for:

  • Simple bug fixes — Just make a single PR
  • Truly independent changes — Use separate branches instead
  • Tiny features — If it’s already small, don’t split it

Next Steps

Section titled “Next Steps”