Skip to main content
Trunk Merge Queue supports merging stacked pull requests: a chain of PRs where each one builds on the previous, with the bottom PR targeting your merge queue branch. Enqueue each PR with /trunk merge and Trunk processes them sequentially, testing and merging each one against the actual state of your merge queue branch.

​
What is a stack

A stack is a chain of pull requests connected through their base branches. Each PR targets the branch of the PR below it, and the bottom PR targets your merge queue branch: 
merge queue branch <-- PR #1 (base: merge queue branch)
                          <-- PR #2 (base: PR #1's branch)
                                <-- PR #3 (base: PR #2's branch)
Trunk discovers the stack automatically by walking base branches. No separate configuration is required to mark PRs as stacked.

​
Step 1: Enqueue every PR in the stack

Each PR in the stack must be enqueued separately. Use any of the standard submission methods on every PR:
  • Comment /trunk merge on each PR.
  • Check the box in the Trunk comment on each PR.
  • Use the CLI: trunk merge <pr-number> for each PR.
Enqueuing each PR separately gives you control over which PRs in your stack should be merged versus which might need more work.

​
Step 2: Automatic sequential processing

Once enqueued, Trunk handles the rest:
  1. The bottom PR in the stack (base branch = your merge queue branch) enters the queue, runs tests, and merges.
  2. When it merges, GitHub automatically updates the next PR’s base branch from the previous feature branch to your merge queue branch.
  3. The next PR now targets the merge queue branch, so it proceeds through the queue.
  4. This continues until every PR in the stack is merged.
For example, a stack of 5 PRs with merge queue branch main:
  • PR #1 (base: main) → tests → merges
  • PR #2’s base automatically changes to main → tests → merges
  • PR #3’s base automatically changes to main → tests → merges
  • …and so on.

​
Considerations

Sequential testing. PRs in the stack are tested and merged one at a time in order. The second PR won’t begin testing until the first PR has fully merged. This ensures each PR is tested against the actual state of your merge queue branch and results are deterministic, at the cost of speed. A stack of 5 PRs takes substantially longer than 5 independent PRs, since they can’t be tested in parallel. Enqueued PRs with non-merge-branch bases. If you enqueue a PR whose base branch is not your merge queue branch and that base never updates, the PR stays in the queue without processing. This typically means the parent PR in the stack was never enqueued or merged. The PR will begin processing as soon as its base branch updates to the merge queue branch. No special configuration. Individual enqueuing requires no additional setup beyond a functioning merge queue. Trunk detects the stack relationship automatically from each PR’s base branch.