The Problem with Excessive Stacked Pull Requests
Overusing stacked pull requests creates unnecessary overhead and complicates the code review process.
1The Logic of Commits
Maintaining readable pull requests relies on two core principles: creating small, logical commits and reviewing them individually. This methodology allows developers to isolate specific changes, making the review process significantly more manageable. When changes are grouped logically rather than alphabetically, reviewers can easily track the evolution of the codebase without unnecessary confusion.
2GitHub Review Limitations
GitHub defaults to a file-based review system, forcing developers to navigate changes in alphabetical order. This structure often obscures the logical flow of complex features. While some developers prefer the Phabricator model, GitHub's current interface prioritizes file lists, which can hinder the ability to review code in a cohesive, sequential manner.
3The Stacked PR Trend
Stacked pull requests have gained popularity as a solution for managing complex dependencies. However, their misuse has led to excessively tall stacks that serve little practical purpose. While they are useful in specific scenarios, they are increasingly being applied to tasks that do not require such a fragmented and serial merging approach.
4Multiplied Operational Overhead
Every additional layer in a pull request stack multiplies the required effort. A stack of fifteen changes results in fifteen times the continuous integration load and fifteen times the code review burden. This exponential increase in overhead creates a bottleneck that slows down development velocity without providing a proportional benefit to code quality.
5Defining Reasonable Limits
Stacked pull requests should be treated as an exception rather than a standard development practice. A reasonable maximum height for a stack should ideally be around five, and even then, only for substantial, complex changes. Exceeding this limit often indicates that the underlying work could have been structured more efficiently from the start.
6Impact on Reviewer Fatigue
Exhausted reviewers are a direct consequence of poorly managed, overly tall pull request stacks. When developers force reviewers to parse through massive, serial chains of code, the quality of the review inevitably suffers. Maintaining a manageable stack size is essential for ensuring that reviewers remain focused and capable of catching critical bugs.
7Refining Development Workflows
To improve team productivity, organizations should prioritize clear, atomic commits over complex stacking strategies. By focusing on the logical grouping of changes, teams can reduce the cognitive load on reviewers. This shift requires discipline in how code is authored and submitted, ensuring that every pull request remains concise, reviewable, and highly focused.
8Strategic Code Management
Effective software delivery requires balancing innovation with maintainable processes. While tools like stacked PRs offer flexibility, they must be used with restraint to avoid overwhelming the development pipeline. Teams should audit their current workflows to ensure that their use of these tools aligns with the goal of sustainable, efficient, and high-quality code delivery.
Original article: Zac Sweers — The Problem with Excessive Stacked Pull Requests