GitHub just shipped a feature that developers have been requesting for years: official support for stacked pull requests. If you've never worked on a large codebase, this might sound like inside baseball. If you have, you know this is a big deal.

Stacked PRs solve a fundamental problem in software development: large code changes are hard to review, slow to merge, and prone to conflicts. Break them into smaller pieces, and you can ship faster with better code quality. The new feature lets developers create ordered chains of pull requests where each PR builds on the one below it, maintaining clear dependencies while keeping individual changes focused and reviewable.

Here's how it works: a new command-line tool called <code>gh stack</code> handles the local workflow - creating branches, managing rebases, and setting up proper base branches for each PR. On the GitHub side, the UI shows reviewers a stack map so they can navigate between layers and understand how changes fit together. When one PR merges, GitHub automatically rebases the remaining PRs in the stack.

This is the kind of infrastructure improvement that doesn't make headlines but meaningfully changes how teams work. The documentation spells out the core problem clearly: "Large pull requests are hard to review, slow to merge, and prone to conflicts. Reviewers lose context, feedback quality drops, and the whole team slows down."

I've shipped code at a startup where we didn't have good tooling for stacked changes. You end up with two bad options: either create massive PRs that nobody reviews properly, or hack together brittle scripts that break whenever someone rebases wrong. Neither is great. Having first-class platform support means teams can adopt the workflow without building their own infrastructure.

What makes this implementation interesting is how <b>GitHub handles branch protection rules.</b> The system is smart enough to enforce rules against the final target branch rather than intermediate branches in the stack. That means you can require passing CI, code review approvals, and other checks without making the intermediate steps unworkable.

Developers have been using third-party tools like Graphite and custom scripts to achieve stacked workflows for years. GitHub building it natively means wider adoption and better integration with existing workflows. It also means the approach is validated - when a major platform adds a feature, it's usually because enough users demonstrated real demand.