The stack is a dependency contract.
GitHub defines a stack as two or more pull requests in one repository. The bottom pull request targets the trunk. Every pull request above it targets the branch below. Each pull request shows the diff for its own layer, not the whole change.[2]
That structure gives reviewers smaller units without pretending those units are independent. Shared types can sit at the bottom. Schema changes can depend on those types. An API can depend on the schema. The interface can depend on the API.
A stack cuts review scope. It does not erase release order.
Merge from the floor up.
GitHub permits one pull request or a contiguous group, starting with the lowest unmerged pull request. A middle pull request cannot merge alone. Everything below it joins the merge group. The merge box reports the state of the stack, and every lower pull request must have approval and passing checks before a higher layer can land.[3]
Merge queues preserve that order. If one pull request leaves the queue, every pull request above it leaves too. The queue can exceed its configured group size by up to 50 percent to keep a stack together. Larger stacks wait for the next merge group.[3]
General availability fixes useful seams.
The October 6 release keeps approvals when unchanged code is rebased after the trunk moves. GitHub signs replacement commits during a stack rebase. The stack enters a merge queue as one merge group. Stack membership now appears in the pull request header and timeline, and the gh stack extension supports Git worktrees.[1]
GitHub reports that repositories using stacks merged 9 percent more code than peers after public preview. It also reports a 5 percent improvement in time to merge among stacked-pull-request users in the top 1 percent of repositories. GitHub does not publish the denominators or a causal study in the release note, so treat both numbers as product telemetry, not proof that stacks will speed up your team.[1]
Budget CI for every layer.
GitHub Actions evaluates each pull request as if it targets the stack base. A workflow triggered for pull requests to main runs for every layer. That keeps checks consistent, but a large stack multiplies CI use. GitHub exposes stack metadata at github.event.pull_request.stack so workflows can reserve expensive jobs for the layers that need them.[4]
The general availability note says auto-merge for stacks is rolling out over several weeks. The merge documentation still says auto-merge is unsupported. Read that mismatch as a staged rollout. Check the repository interface and current documentation before scripting around the new control.[1][3]