Test the merge, not the branch

Two pull requests merged eleven minutes apart on a Thursday afternoon. Both had green checks. Both were reviewed, approved, and correct. Main was broken by 4 p.m., and the paradox is that it was broken by two changes that were each, individually, fine.

One PR renamed a helper function and updated every caller. The other PR, written before the rename, added a brand-new caller using the old name. No line of code conflicted, so Git merged both without a murmur. The test suites had each run against the version of main that existed when their branch was cut, and both of those worlds were internally consistent. Neither world was the one that actually shipped.

(The two authors sat three meters apart. Proximity is not a merge strategy.)

Green means your branch worked in a world that no longer exists

Standard CI has a blind spot built into its geometry. Checks validate a branch against the base commit it forked from, and the interesting failures happen in the gap between that snapshot and the moment of merge. On a quiet repository the gap is minutes and the bet usually pays. On a busy one, ten merges a day into a shared trunk, the gap is where semantic conflicts breed: renames colliding with new usage, a schema migration landing under a feature that assumed the old shape, two features each claiming the same config default.

Teams discover this failure class and reach for rituals. "Update your branch before merging" works until two people update simultaneously. Locking main behind a human merge marshal works at the price of making a person the throughput ceiling. The real fix is mechanical.

A merge queue changes what gets tested. Instead of merging your approved branch directly, you hand it to the queue, and the queue constructs the speculative future: main plus every PR ahead of you plus yours, merged in order. CI runs against that constructed state, the world as it will actually exist at your merge moment, not the world as it was at your branch point. Pass, and the merge happens automatically. Fail, and your PR is ejected while the queue re-tests the remaining candidates without it, and main never learns your name.

The idea has an honorable open-source lineage: the Rust project ran it for a decade as Bors, and bors-ng carried the pattern to everyone else. Today it is a checkbox in GitHub's merge queue and GitLab's merge trains, and Mergify offers it with batching for teams whose CI minutes are precious. Batching matters at scale: test eight queued PRs as one combined state, and only bisect into smaller groups when the combined run fails. High-traffic monorepos merge hundreds of changes a day this way with a trunk that effectively never breaks.

The queue tests the future, and the future is the only thing worth testing.

The direct win is the absence of a category: no more "main is red, who broke it" archaeology, no more all-hands rollback while forty engineers rebase around the wreck. The quieter win is behavioral. When trunk breakage stops being a background risk, deploys from main stop being acts of courage, and continuous deployment goes from aspiration to default. A broken main costs every engineer on the team simultaneously, which makes it one of the most expensive artifacts in your company, and one of the few that a configuration change can genuinely eliminate.

We rolled this pattern out for a team of about twenty engineers whose trunk broke four or five times a month, always from green PRs, always at the worst hour. Setting up the queue took an afternoon; tuning the batch size took a week. In the five months since, the queue has ejected 23 pull requests that would have broken main, and main itself has been red exactly zero times. At TensorLabs we do this kind of delivery-pipeline work alongside the AI systems we build, because a model you cannot ship safely is a demo. Your checks are probably fine. Point them at the right world.