GitHub introduces Stacked Pull Requests in public preview to break large changes into smaller, dependent reviews

GitHub has announced that Stacked Pull Requests are now available in public preview, introducing native support for breaking large software changes into smaller, dependent pull requests. Developers can organize work into a sequence of pull requests, each building on the previous one, allowing reviewers to evaluate each logical change independently. This implementation preserves existing branch protection rules, review workflows, and merge policies. It makes stacked development a natural extension of existing repository practices rather than requiring a separate workflow.

By incorporating this capability directly into GitHub, Microsoft removes much of the operational overhead that previously discouraged widespread adoption. Teams can now create, review, update, and merge dependent pull requests using familiar GitHub workflows without introducing additional tooling into their engineering environments. Previously, GitHub teams relied on third-party tools or manual branch management to achieve comparable results. Companies such as Graphite and Sapling have built dedicated tooling around similar workflows, but native integration eliminates the need for these external dependencies.

The timing of the announcement reflects a broader industry shift where AI coding assistants generate substantial amounts of production-ready code, but code review remains largely a human activity. Stacked pull requests attempt to solve the resulting bottleneck by reducing review scope rather than accelerating review itself. Each pull request represents a single logical step, such as introducing a new API or updating a database schema, making smaller reviews easier to understand and validate. However, if projects rely on a single experienced reviewer to validate agent-generated contributions, even structured review processes may struggle to keep pace as coding agents become more capable.

Beyond improving reviews, stacked pull requests also support better developer flow by allowing development to continue on top of earlier work while reviewers evaluate each layer independently. This reduces the need for large, long-lived feature branches that frequently suffer from merge conflicts and stale code. It encourages developers to think about software changes as incremental architectural improvements rather than monolithic feature deliveries. This practice is already associated with lower deployment risk and faster feedback.