スタックドプルリクエストがパブリックプレビューで利用可能にStacked pull requests are now in public preview

GitHub has made stacked pull requests available in public preview, giving developers a native way to split large code changes into an ordered series of smaller, individually reviewable pull requests. The feature targets a long-standing pain point in code review: sprawling pull requests that bundle many concerns together are slow to review, hard to reason about, and can delay the delivery of otherwise ready work.

At its core, a stacked pull request is a sequence of dependent pull requests, each building on the one before it. Rather than opening a single pull request that contains an entire feature, a developer can break the work into focused layers—for example, a data model change, then the business logic that uses it, then the user interface that surfaces it—and open a separate pull request for each layer. Each pull request in the stack represents a discrete, self-contained unit of change that reviewers can evaluate on its own, while the ordering preserves the dependencies between the layers.

The approach addresses a familiar tension in team-based development. Small pull requests are easier and faster to review, but real-world features often cannot be expressed as a single small change. Traditionally, developers who wanted to keep their work moving had to either wait for an early pull request to merge before starting the next piece, or manually juggle a chain of Git branches that depend on one another. Managing those dependencies by hand is error-prone, particularly when an earlier branch changes and every branch downstream needs to be updated. Stacked pull requests aim to formalize and automate that workflow inside GitHub itself.

For developers, the practical appeal is continuity. With stacks, a contributor can keep building later parts of a feature while earlier parts are still under review, and updates to a lower pull request in the stack can propagate to the ones above it. This can shorten the feedback loop and reduce the idle time that comes from waiting on reviews. For reviewers, smaller and more focused pull requests can make it easier to understand the intent of each change and to provide targeted feedback, which in turn can improve review quality.

The concept is not new to the wider industry. Stacked, or "stacked diff," workflows have been popularized by tools and platforms outside GitHub. Graphite, a startup focused on code review, built its product around stacking, and Meta's open-source Sapling source control system, along with review systems such as Gerrit, have long supported change-by-change review models. Bringing a comparable capability into GitHub natively is likely to lower the barrier for teams that previously relied on third-party tooling or custom scripts to achieve the same result.

Because the feature is in public preview rather than general availability, teams should expect it to evolve. Public preview typically means the functionality is broadly accessible for testing and feedback but may still have rough edges, changing behavior, or incomplete integration with other parts of the platform. GitHub commonly uses this stage to gather input before committing to a stable, generally available release, and details such as the interface, supported clients, and enterprise controls can shift during the period.

The release also fits into a broader pattern of GitHub investing in the code review experience and developer workflow. Pull requests remain central to how millions of projects collaborate, and incremental improvements to how changes are proposed, organized, and merged have a direct effect on developer productivity.

Teams interested in the capability can enable it through the public preview and begin experimenting with stacked workflows on their repositories. As with any change to established habits, adopting stacked pull requests may require adjusting review conventions and continuous integration setups, since each pull request in a stack can trigger its own checks. Organizations that already practice trunk-based development, or that value small and frequent merges, are likely to find the model a natural fit, while others may want to trial it on a limited set of projects before a broader rollout. Feedback gathered during the preview will probably shape how the feature behaves when it reaches general availability.