What does GitHub's merge queue prevent that required checks on a pull request cannot?
answer
- green against which base, exactly
- two clean merges, one broken base
- tested in the order it will land
- the queue updates instead of the author
- speculation buys back throughput
basics
~20 sIt prevents changes that were only ever tested apart from breaking the base once combined. The queue re-tests each pull request against the base plus everything landing ahead of it, in the exact order, and merges only if that combination is green.
solid answer
~50 sRequired status checks prove that a pull request was green **against the base it was tested on**, which may be several merges stale. Two pull requests can each be green and still break `main` together — one removes a function the other starts calling, and no CI run ever saw both. GitHub's merge queue closes that gap without the human toil: instead of merging, the author selects **Merge when ready**, GitHub places the pull request in an ordered queue, builds a temporary ref containing the base plus every entry ahead of it plus this one, runs the required checks against that ref, and merges only when it passes. It keeps the guarantee that "require branches to be up to date" gives you, but it does the updating and re-testing itself, in parallel across speculative entries, so authors are not serialised behind each other's CI runs.
go deeper
Recall that clicking Merge when ready adds the pull request to a queue instead of merging it, and that GitHub tests the change together with whatever lands ahead of it.
Explain the semantic-conflict failure and contrast the two fixes: requiring an up-to-date branch, which serialises authors, versus a queue that re-tests in landing order and builds entries in parallel.
Judge when a repository has enough merge pressure to justify the extra CI spend, and recognise that a queue amplifies flaky tests rather than tolerating them.
Own the throughput model for the organization: merge rate against CI duration, what the queue costs in runner minutes, and which repositories should get one rather than a blanket rollout.
## The gap the queue fills Branch protection can require named checks to be successful before a pull request merges. The result those checks report belongs to the pull request's head commit, which contains your branch merged with *some* base commit. If the base has moved since, the evidence is about a combination that will never exist. The failure it lets through is a **semantic conflict**: two changes that do not touch the same lines, so Git merges them without complaint, but whose meanings collide — a renamed symbol and a new caller, a tightened validation and a fixture that no longer satisfies it, a removed feature flag and a new read of it. The classic mitigation is the **"Require branches to be up to date before merging"** condition: a pull request cannot merge unless its branch already contains the base tip. That does close the gap, because CI then ran on the true combination. Its cost is serialisation. Every merge invalidates every other open pull request; each author must click *Update branch* and wait a full CI cycle, and only one of them can win the next slot. At `N` open pull requests and a CI duration of `T`, merge throughput tends toward one change per `T`, and engineers start racing for the button. ## What the queue does instead A merge queue is enabled on the target branch (through branch protection or a ruleset). Once it is on, the pull request's merge control becomes **Merge when ready**: clicking it does not merge, it enqueues. GitHub then, for each entry, creates a temporary branch under `gh-readonly-queue/` containing the base branch, the changes of every entry ahead in the queue, and the entry itself, and runs the required checks against that ref. If they pass and everything ahead of it has landed, GitHub merges the entry into the base using the configured merge method. If they fail, the entry is removed and the entries behind it are rebuilt without it. Two properties matter: - **Order is the same order it will land in.** The thing tested is exactly the thing that becomes `main`, which is the guarantee required checks alone cannot give. - **It is speculative.** GitHub can build several entries concurrently, each optimistically assuming the ones ahead will succeed. That is what recovers throughput: the queue is not one-CI-run-per-merge, it is a pipeline. ## What it does not do - **It is not a substitute for required checks** — it uses them. The checks required on the branch are what the merge group must satisfy; a repository with no required checks gains nothing from a queue. - **It does not fix flaky tests.** In fact it punishes them: a flake in a merge group takes out an entry that was perfectly fine and forces a rebuild of everything behind it. Repositories with a meaningful flake rate should quarantine before queuing. - **It does not replace review.** Approvals, ownership-based review, conversation resolution and every other pull-request gate still apply before an entry may join the queue. - **It does not eliminate breakage from outside the queue.** A change pushed directly to the base, or landed with a bypass, was never tested in order. ## When it is worth it The queue earns its keep when merge attempts per CI-duration approach or exceed one — a repository where developers are visibly waiting for each other's *Update branch* cycles. Below that, strict required checks are simpler and cheaper: fewer moving parts, no extra CI runs, no configuration to get wrong. Above it, the queue converts developer waiting into machine parallelism, and you pay for that in CI minutes. ## Configuration surface, briefly The queue is a rule on the branch, and its parameters control the throughput/cost tradeoff: the merge method used to land entries, how many entries may be built at once, minimum and maximum entries per group, how long to wait before forming a group, and how long to wait for checks before giving up on an entry. Those knobs are where the interesting judgment lives, and they are the natural follow-up to this question. ## Interview framing Name the failure — two individually green changes breaking the base — then contrast the two platform answers to it: the up-to-date requirement (correct, serialising, manual) and the merge queue (same correctness, order-preserving, parallel, costs CI). Mention that the queue tests a temporary ref containing the base plus everything ahead, and that *Merge when ready* enqueues rather than merges, and you have shown you know the mechanism rather than the marketing.
- Does a merge queue remove the need for required status checks on the branch?No — it consumes them. The checks required on the target branch are what the merge group must satisfy, so a repository with no required checks gains nothing from a queue. The queue changes *what* the checks run against, from your branch alone to the combined result, not whether checks exist.
- Which repositories should not turn a merge queue on?Low-volume ones, where fewer than one merge is attempted per CI cycle — strict required checks are simpler and cheaper there. And any repository with a meaningful flake rate, because a queue converts each flake into an evicted pull request plus discarded speculative work, which feels arbitrary to the authors caught by it.
- Can something still break the base branch while a merge queue is enabled?Yes. The queue only guarantees changes that go through it. A direct push permitted by the branch rules, a merge landed by a bypass actor, or a change to something outside the repository the tests depend on all reach the base without ever being tested in queue order.
saying these in an interview costs you the question
- Says a merge queue removes the need for required status checks
- Thinks the queue merges immediately and reverts on failure
- Believes it prevents textual merge conflicts
- Claims it helps a repository with one merge a day
- Assumes flaky tests are harmless once a queue is in place