GitHub Stacked PRs: Break Big Changes Into Small Reviews

A Growing Movement in Code Review Is Reshaping How Teams Ship Software on GitHub

The concept of stacked pull requests — a technique where developers decompose massive code changes into a sequence of small, interdependent PRs — is gaining serious traction across the GitHub ecosystem. What was once a niche practice among elite engineering teams at companies like Google and Meta has sparked fresh discussion in the broader developer community, signaling a potential shift in how modern software teams approach code review.

The conversation, which recently resurfaced on developer forums and social platforms, centers on a deceptively simple idea: instead of submitting one enormous pull request with hundreds of changed lines, developers should break their work into a chain of smaller, focused PRs that build on each other. Each piece in the stack addresses a single concern, making it dramatically easier for reviewers to understand, critique, and approve.

What Exactly Are Stacked PRs?

Traditional pull request workflows on GitHub follow a straightforward pattern. A developer creates a feature branch, works on it — sometimes for days or weeks — and then opens a single PR against the main branch. The result is often a sprawling diff that no reviewer genuinely wants to wade through.

Stacked PRs flip this model. Instead of one monolithic submission, the developer creates a chain of branches where each subsequent branch is based on the previous one. Each branch gets its own pull request, and each PR targets the branch below it in the stack rather than main. The workflow looks something like this:

• PR 1: Refactor the database schema (targets main)
• PR 2: Add the new API endpoint (targets PR 1’s branch)
• PR 3: Build the frontend component (targets PR 2’s branch)
• PR 4: Wire everything together with tests (targets PR 3’s branch)

Each individual PR is small enough to review in minutes rather than hours. Reviewers can approve and merge them sequentially, and the entire feature lands in main only after every piece has been vetted.

Why This Matters Right Now

The timing of this renewed interest isn’t accidental. Engineering organizations are under mounting pressure to ship faster without sacrificing code quality. Research from Google’s DORA team has consistently shown that elite-performing teams deploy more frequently and maintain shorter lead times — both metrics that benefit from smaller, more digestible changes.

Large pull requests are one of the most commonly cited bottlenecks in software delivery. Studies suggest that PRs exceeding 400 lines of changes see review quality plummet, with reviewers more likely to rubber-stamp approvals rather than catch bugs. When teams break changes into small, focused units, review thoroughness improves significantly.

For teams already using GitHub as their collaboration hub, stacked PRs represent an evolution rather than a revolution. The underlying Git mechanics have always supported this workflow, but tooling and cultural norms lagged behind. That gap is closing fast. If you’re exploring ways to optimize your team’s delivery pipeline, our coverage of ContextPool: Persistent Memory for AI Coding Agents offers additional strategies worth considering.

The Tooling Ecosystem Catching Up

One reason stacked PRs historically struggled to gain mainstream adoption is that GitHub’s native interface doesn’t provide first-class support for managing stacks. Rebasing a chain of dependent branches manually is tedious and error-prone — a single merge conflict can cascade through every branch in the stack.

That’s where a growing ecosystem of third-party tools enters the picture. Several notable options have emerged:

1. Graphite: Perhaps the most well-known stacked PR tool, Graphite provides a CLI and dashboard purpose-built for managing stacks on GitHub. It automates rebasing, tracks dependencies, and integrates directly with GitHub’s API.
2. ghstack: Originally developed at Meta for internal use, this open-source tool maps individual commits to separate GitHub PRs automatically.
3. git-town: A Git extension that simplifies branch management workflows, including stacking patterns.
4. Aviator: A merge automation platform that includes stacked PR support alongside its queue-based merging system.

These tools abstract away the painful parts — the constant rebasing, the dependency tracking, the merge ordering — and let developers focus on writing clean, reviewable code.

What Engineering Leaders Are Saying

The engineering culture at companies like Google, where code review has long been conducted on small, atomic changesets (known internally as CLs), has heavily influenced this trend. Engineers who transition from Google to GitHub-centric organizations frequently advocate for stacked workflows as a way to replicate that review discipline.

The consensus among experienced engineering managers is clear: smaller PRs correlate with faster merge times, fewer defects in production, and healthier team dynamics. Reviewers feel respected when they’re asked to evaluate 100 lines rather than 1,000, and authors get feedback sooner — creating a tighter iteration loop that benefits everyone.

However, skeptics raise valid concerns. Stacked PRs add coordination overhead, require team-wide buy-in, and can create merge conflicts when multiple developers work on adjacent areas of the codebase. The workflow demands a level of Git proficiency that not every team possesses.

What Comes Next for GitHub and Stacked Workflows

The big question is whether GitHub itself will build native stacking support into its platform. With Microsoft’s resources behind it and clear demand from the community, it’s not unreasonable to expect first-party features that make managing dependent PRs less painful. GitHub has steadily expanded its code review capabilities in recent years, and stacked PR support would be a natural next step.

In the meantime, the third-party ecosystem will continue to mature. Graphite recently raised significant funding, and competitors are iterating rapidly. The combination of AI-powered code review tools and stacked PRs could prove particularly powerful — smaller, more focused diffs give AI assistants better context to provide meaningful suggestions. For more on how artificial intelligence is reshaping development, check out our guide on ContextPool: Persistent Memory for AI Coding Agents.

The Bottom Line

Stacked PRs aren’t a silver bullet, but they represent a meaningful improvement over the status quo for teams drowning in oversized code reviews. The core principle — break your work into small, logical units that humans can actually review thoughtfully — is sound engineering practice regardless of what tools you use.

For GitHub-centric teams looking to ship faster without cutting corners on quality, now is the time to experiment with stacked workflows. The tooling has matured, the community knowledge base is growing, and the evidence strongly favors smaller changes as a path to better software.