Skip to main content
Trunk Merge Queue supports GitHub’s native stacked pull requests. You can submit any part of a stack the same way you submit a regular PR (API, browser extension, PR comment, or checkbox), and Merge Queue handles moving each segment through the queue and merging it.
Image

​
How it works

Given a stack like:
Image
You can submit from any point in the stack. So it is acceptable to enqueue from mid-stack - for example PR2 or from the top of the stack PR4. You don’t have to wait for one part of a stack to merge before enqueuing another part. It is perfectly ok to enqueue from PR2 and from PR4 at the same time. We will sort it out and make sure all the code is tested correctly.

​
Tracking a Stack in the Queue

When you submit a stack the entry in the Merge Queue UI will reflect all the pull requests that are being tested collectively as seen below
Image

​
Performance

Because the Trunk Merge Queue is stack aware you will achieve CI performance savings and throughput wins when submitting stacks as we will test the stack of PRs as a single block instead of testing each PR in the stack individually.

Things to know
  • GitHub may not always rebase after a mid-stack merge. There are some existing issues from GitHub surrounding stacks when performing a mid-stack merge. While GitHub is intending to always rebase stacks correctly - you may still need to manually rebase the existing pieces of your remaining stack after Merge Queue merges the pieces underneath it. GitHub is working on improving this behavior.
  • GitHub’s stack merge API can take 90+ seconds to complete. Stacks may stay in the “merging” state longer than a regular PR while GitHub finishes the merge.