Beyond Massive PRs: How Stacked Pull Requests Accelerate Engineering Velocity

The giant Pull Request is a persistent bottleneck in modern software engineering. Shipping complex, multi-layered features—spanning database migrations, core API logic, background queues, and frontend interfaces—in a single branch often results in an unmanageable behemoth of a diff.

This creates severe cognitive friction for reviewers, degrades the thoroughness of security checks, and causes long-standing feature branches to devolve into merge conflict nightmares. To sustain high-velocity shipping without compromising quality, engineering organizations are moving toward Stacked Pull Requests—a workflow that decomposes large developments into atomic, sequential, and independently reviewable units.

In Simple Terms: The Building Block Analogy

If the concept feels abstract, think of writing complex software like constructing a multi-story building.

A monolithic, giant PR is like trying to build the entire skyscraper in secret, and then asking the city inspector to approve the foundation, the plumbing, the electrical wiring, and the roof all in a single afternoon. It is completely overwhelming, and critical mistakes will inevitably slip through the cracks because there is simply too much to look at.

Stacked PRs change the process into phased, logical construction. You pour the foundation and submit it for a quick inspection (PR #1). While the inspector is looking at the foundation, you don't just sit around waiting—you immediately start building the first floor (PR #2) right on top of that foundation. Each phase is a separate "stack" that can be reviewed and approved independently. It transforms an overwhelming mountain of code into digestible, bite-sized checkpoints.

Understanding the Architecture of Stacked Pull Requests

In a standard Git workflow, feature branches are created directly off the repository's primary branch (main or trunk) and target that same branch upon completion.

Plaintext

A stacked pull request architecture breaks this paradigm. Instead of branching directly off and targeting main, each subsequent branch targets the branch directly below it in the stack.

Plaintext

A Practical Example

Consider developing an enterprise asynchronous vulnerability scanning pipeline. In a single, massive PR, a reviewer must simultaneously evaluate database schemas, queue concurrency, execution logic, and event formatting. In a stacked workflow, this is neatly compartmentalized:

1. PR #1 (Data Layer): Database schemas and migration scripts. (Targets: main)
2. PR #2 (Execution Engine): Asynchronous worker pool and task routing. (Targets: PR #1)
3. PR #3 (Integration Layer): SIEM event formatting and webhooks. (Targets: PR #2)

Reviewers evaluate changes in a logical sequence rather than struggling to comprehend the entire pipeline at once.

Core Advantages of Stacked Development

Transitioning to a stacked workflow fundamentally alters how software is built and reviewed:

1. Eliminating Reviewer Fatigue: Massive pull requests overwhelm reviewers. By serving small, focused units of work (e.g., under 200 lines), teams achieve significantly higher review fidelity and catch defects earlier.
2. Unblocked Authoring: You don't have to wait for PR #1 to be merged to start PR #2. You branch directly off your local PR #1 and keep coding, remaining in a continuous flow state.
3. Fewer Merge Conflicts: Stacking enforces smaller, frequent merges into main, continuously integrating incremental changes and minimizing code drift.
4. Surgical Rollbacks: If a bug reaches production, reverting a giant PR backs out the entire feature. With stacked PRs, you can selectively revert just the flawed layer (like the UI) while keeping the foundational infrastructure intact.

The Technical Challenge: The Cascading Rebase

Managing stacked branches manually presents a notable technical challenge. Because Git models commits as a Directed Acyclic Graph (DAG), modifying an earlier commit changes its hash. If a reviewer requests changes on PR #1, updating it severs its historical link to PR #2 and PR #3.

Plaintext

To repair this manually, a developer must execute a series of selective rebases using git rebase --onto. Doing this across deep stacks is tedious and error-prone.

Modern Tooling Automates the Stack

To eliminate the friction of manual rebasing, modern tooling automates dependency tracking:

1. Graphite (graphite.dev): A dedicated CLI and web interface for stacked workflows. Commands like gt sync automatically track dependencies and handle cascading rebases.
2. Spr (Stacked Pull Requests): An open-source CLI inspired by internal developer tools at Google and Meta to manage stacks natively from a single Git branch.
3. GitHub Native Auto-Retargeting: GitHub now natively supports automatically updating the base branch of dependent PRs when a parent PR is merged.

Conclusion

Shipping complex software requires balancing rapid iteration with rigorous quality controls. Giant pull requests force a choice between review quality and delivery speed. By adopting stacked pull requests, teams decouple feature complexity into manageable steps, resulting in faster code reviews, zero downtime waiting for approvals, and a cleaner repository history.