gh stack で PR を積んでみた ── リベースは自動、ただし直列しか組めないA hands-on trial of GitHub's stacked PR feature (public preview July 2026) with…

GitHub has begun a public preview of a native stacked pull request workflow, made available on 30 July 2026, and a recent hands-on trial suggests it handles one of the format's most persistent pain points—squash merges—more gracefully than many longtime practitioners might expect. Stacked PRs let developers split a large change into a chain of smaller, dependent pull requests that build on one another, making each piece easier to review while keeping the overall work moving. Whether GitHub's implementation preserves clean history through merges has been the central open question, and the new tooling appears to address it directly.

The trial was conducted on a personal private repository with a three-layer stack, and the reviewer's primary concern was whether squash-merging the bottom PR would corrupt the history of the layers above it. In practice, it did not. The moment the lowest PR was squash-merged, GitHub automatically retargeted the base of the next PR in the stack to main on the server side, so the remaining pull requests did not point at a now-merged branch. This automatic retargeting removes a manual step that has historically forced developers to babysit each merge.

Squash merges are notoriously awkward for stacked workflows because they collapse a branch's commits into a single new commit, discarding the original commit objects that upper branches were built on top of. That normally breaks the linear relationship between layers. Here, the linearity lost to the squash is restored by running gh stack sync, which the reviewer observed reporting "adjusted for merged PR" as it rebased the remaining work onto the new squash commit. The result is that the stack continues to sit cleanly on top of main rather than diverging or duplicating commits.

The scope of the feature, however, is clearly narrow. It is limited to a single repository, and cross-fork stacks are not supported, which rules out the common open-source contribution pattern where changes flow from a personal fork into an upstream project. Just as importantly, the tooling only builds serial, linear stacks. Developers cannot assemble a branching or tree-shaped arrangement where multiple PRs share a common base and diverge—each layer must sit directly on the one below it. For teams whose work naturally fans out into parallel tracks, that constraint is likely to be a meaningful limitation during the preview.

Context helps explain why this matters. Stacked pull requests are not a new idea, and several third-party tools have grown up to fill the gap that GitHub's default workflow left open. Graphite, git-town, Meta's ghstack, the Sapling source-control system, and the spr command-line tool all offer variations on stacking, each with its own conventions for tracking dependencies and re-syncing after merges. The recurring difficulty across all of them is exactly the scenario tested here: keeping the chain intact once a lower PR lands, especially under squash merges. By building retargeting and sync into the official GitHub CLI, GitHub is bringing a first-party option to a workflow that until now required external tooling or careful manual rebasing.

The gh stack commands extend the GitHub CLI, the official command-line client for interacting with pull requests, issues, and other repository operations. Positioning the feature there, rather than solely in the web interface, signals that GitHub is targeting developers who already manage branches and reviews from the terminal. Because this is a public preview rather than a general release, the behavior, command surface, and supported scenarios could still change before any stable version, and the current same-repository limitation may or may not be relaxed over time.

For now, the practical takeaway from the trial is measured but positive: automatic base retargeting and gh stack sync together preserve a linear history through squash merges in a simple three-layer stack, which is the reassurance many stacked-PR skeptics have been waiting for. The absence of cross-fork support and branching stacks means the feature is best suited, at least during the preview, to individuals and teams working within a single repository on straightforward, linear chains of changes.