Trunk Merge Queue vs GitHub Merge Queue

Both work with any CI provider that reports status checks to GitHub — Actions, CircleCI, Buildkite, Jenkins, and more.

Trunk runs all queue optimizations around the merge, not inside it. Temp branches are test-only scaffolding; the commit landing on main is a normal merge — the same one a developer would run by hand. GitHub’s queue constructs the merged state itself, which is how the April 2026 incident silently reverted thousands of lines of already-shipped code.

Trunk holds failed PRs while downstream PRs continue to test. If a downstream PR’s passing result proves the earlier failure was a flake, both PRs merge automatically with no manual requeue. GitHub has an opt-in setting that delays ejection but offers no detection or quarantine — you still need to figure out which test is flaky and what to do about it.

Trunk infers parallel lanes dynamically from the targets a PR actually impacts, so unrelated changes test concurrently and merge independently. GitHub validates up to 100 PRs concurrently in CI but merges them in a single FIFO order — a slow check on one PR still blocks everything queued behind it.

Both group PRs into batches and run CI on combined merge groups. The differences: Trunk integrates batching with parallel queue mode and bisects with test caching on failure, so prior passing results aren’t re-run. GitHub validates merge_groups but on failure rebuilds the queue and re-tests the surviving PRs from scratch.

Both test the projected state of main ahead of time. The meaningful difference: when a speculative check fails due to a flake, Trunk recovers automatically while GitHub ejects the PR and rebuilds the queue.

If a later speculative check that includes a PR passes before the earlier ones complete, Trunk merges without waiting. Fewer CI runs, lower latency, same correctness guarantee. At high PR volume this compounds into significant throughput gains.

Trunk’s /trunk stack command combines a chain of dependent PRs into a single stacked PR that moves through the merge queue together. GitHub’s native queue treats each PR independently, so stacks have to be merged one at a time and re-tested with every step.

Trunk’s Sudo App is a dedicated GitHub App that handles emergency-bypass merges. Trunk verifies admin identity via the GitHub comment authorship that triggered the bypass, so the action is recorded against a specific user. GitHub itself requires a repo admin to override branch protection through GitHub’s UI, with no Trunk-side gating.

Trunk supports granular priority levels and Direct Merge for PRs landing on a tip-of-main with an empty queue. GitHub offers a binary “jump queue” option; using it triggers a full rebuild of all in-progress PRs, which slows overall merge velocity.

Trunk’s parallel queue mode reads which Bazel targets a PR actually affects and tests only the relevant lanes. In a large Bazel monorepo this is the difference between a working queue and a queue that’s constantly bottlenecked on unrelated changes.

When your queue backs up at 4pm on release day you need to know why. Trunk’s health page surfaces Time in Queue (P50/P95/P99) and Conclusion Count over time, with drill-down from any chart point to the specific PRs in that bucket — which passed, which failed, which were cancelled, and why. GitHub’s PR timeline shows the reason a PR was removed from the queue, but no aggregated metrics.

Trunk ships a full REST management API for queue configuration and PR operations, plus lifecycle and batch webhooks with detailed failure reasons. GitHub exposes a limited GraphQL surface for PR enqueue/dequeue and a minimal merge_group webhook focused on triggering CI.

Trunk includes 24/7 PagerDuty on-call for system-critical issues on Enterprise. GitHub support follows standard plan tiers; queue-specific incidents do not have a dedicated SLA.