A button on pull request B can represent a decision about A and B together. Before merging a GitHub stack, write down the lowest unmerged layer, the highest layer you intend to include and the branch that will receive the result. That small boundary record makes the scope of the operation easier to review.
GitHub announced general availability of stacked pull requests on October 6, 2026. The release adds improvements around approvals after unchanged rebases, signed replacement commits and keeping stacks together in merge queue. It also announces an auto-merge rollout over the following weeks. This guide uses a read-only worksheet to prepare a merge decision; it does not require enabling auto-merge, bypassing rules or installing a CLI extension.
Draw the dependency order before choosing a boundary
In GitHub's stack reference, each pull request targets the branch below it, while the bottom one targets the trunk. The trunk may be the default branch or another branch. GitHub evaluates each layer against the rules for that stack base, including layers that do not directly target it.
Consider this fictional three-layer change:
| Bottom-to-top order | Purpose | Direct base |
|---|---|---|
| A | Add a shared response type | main |
| B | Add an API route using that type | A's branch |
| C | Add a screen using that route | B's branch |
The letters identify imaginary pull requests, not commit hashes or actual repository names. In your own record, replace them with links and current head revisions. Include the trunk explicitly; a stack aimed at a release branch is a different operation from one aimed at main.
Mark the included range and what stays out
GitHub's merge instructions say that a selected group must begin with the lowest unmerged pull request and remain contiguous. Selecting a middle layer also includes the unmerged layers below it. You cannot select an isolated middle layer and leave its lower dependencies unmerged.
With A, B and C all unmerged, selecting B therefore means the proposed range is A through B, with C remaining outside it. After A has already merged, the lowest unmerged layer changes. Read the current stack again instead of reusing the old drawing.
| Current observation | Proposed highest included layer | Range to review | Outside the range |
|---|---|---|---|
| A, B and C are unmerged | A | A | B and C |
| A, B and C are unmerged | B | A and B | C |
| A, B and C are unmerged | C | A, B and C | None of these three |
| A is merged; B and C remain unmerged | B | B, using the refreshed stack state | C |
Before acting, compare that range with the change you actually intend to land. If the request was only to review B, do not turn it into a merge of A and B. If the authorized scope and the stack's required range differ, resolve that difference before choosing a merge action.
Keep evidence on the same row as the revision
The stack reference requires the selected pull request and the layers below it to meet the stack base's protections, and the stack must have a linear history. A lower-branch change or movement of the trunk can make a rebase necessary. Use the current merge box and checks rather than a screenshot from an earlier review.
For each included layer, make a row with these fields. The worksheet is an inspection aid, not a substitute for GitHub's enforcement.
- Identity: pull request URL, head revision and current direct base.
- Change being included: a plain-language description of that layer's diff.
- Required review evidence: current review state and any unresolved requirement.
- Required check evidence: check links, conclusion and the revision or merge context they evaluate.
- Uncertainty: missing evidence, a changed dependency or a fact that needs an owner to resolve.
Do not record a generic green badge as the entire test story. Read the named checks that matter to the repository, and distinguish a pending result from a completed one. For a check that reports on a synthetic merge revision, retain that context rather than relabeling it as a test of the branch head alone.
Recheck after a rebase or stack change
The October 6 announcement says that approvals can remain when a stack is rebased after its base advances and the code's diff stays unchanged, even where stale approvals are normally dismissed. That behavior is useful context; a retained approval still does not tell your worksheet whether the merge range, required checks or intended destination changed.
Refresh the record if the stack membership, head revisions, trunk, selected upper boundary or check results change. Write what changed before replacing the old observation. A concise note might be: “B's head revision changed after the rebase; reread its current diff and check links.” This is a proposed review habit, not a claim that every rebase invalidates every approval.
Availability also deserves a dated note. The release announces auto-merge rollout, while the merge guide still contained an unsupported-auto-merge note when checked on October 7. Verify what your repository actually offers before relying on that feature. The boundary worksheet works without it.
Separate the request from the observed result
If an existing authorized automation uses the API, GitHub's stack API documentation requires the asynchronous merge endpoint. Submission starts background work; repository rules are evaluated when the merge runs, and polling can report a later failure. An accepted request therefore needs a result check.
For either the website or an existing integration, record the outcome you can observe for every included pull request. Do not infer all final states from the disappearance of a button or a single completed notification. If an operation is interrupted or the result is unclear, inspect the remote state before repeating it.
| After-action field | Evidence to keep |
|---|---|
| Included pull requests | The recorded range, plus each pull request’s observed merged/open state, plus any queue status or merge-request failure |
| Destination | The receiving branch and resulting revision, when available |
| Remaining stack | Its current lowest unmerged layer and base relationship |
| Verification | Relevant post-merge checks or release validation and their exact revisions |
| Unresolved work | A named blocker and next authorized step, without inventing a success state |
GitHub documents automatic rebasing and retargeting of the next unmerged layer after a lower merge. Confirm that resulting relationship in your own stack before preparing another boundary. Merge completion and a working deployment remain separate observations.
Copy this merge-boundary record
- Checked at / repository: __________
- Trunk and observed revision: __________
- Lowest unmerged pull request: __________
- Highest intended included pull request: __________
- All included pull request links, bottom first: __________
- Layers intentionally left out: __________
- Current head revisions and direct bases: __________
- Required review / check evidence and unresolved items: __________
- Who authorized this exact range and destination: __________
- What changed since that decision: __________
- Observed result for each included layer: __________
- Resulting branch revision and remaining-stack state: __________
- Post-merge verification / next owner: __________
Use the record to answer one concrete question before a merge: “Which changes are included in this action right now?” For the longer-lived evidence you want to retain afterward, see the release evidence handoff guide. If a green workflow includes code coverage, the coverage upload receipt explains a separate verification boundary.