From Bors and Homu to Bulldozer, Kodiak, Mergify, and now GitHub and GitLab, merge queues have shaped how we keep main branches green. This article traces their history, why they emerged, and how they became a standard in modern software development.
If you use GitHub or GitLab today, merge queues feel like a built-in feature of modern development. But their story goes back over a decade, long before "merge queue" was a product term.
It started with a simple problem: How do you keep your main branch green when dozens of developers are merging code simultaneously? Continuous integration clarified that "just merge and hope" wasn't good enough. The solution wasn't a new testing framework but a new workflow.
From early scripts in the Rust project (Bors, Homu) to Shopify's Shipit , to modern SaaS offerings like Mergify and built-in queues from GitHub and GitLab, merge queues evolved out of necessity. What began as side-project bots has become a standard practice for engineering teams at scale.
This post walks through that history — the motivations, the people behind it, and how these tools shaped the way we merge code today.
The "Not Rocket Science" Rule and Early Experiments
The idea of a merge queue – automatically ensuring that a main branch is never broken by merged changes – can be traced back over two decades. In the early 2000s, developer Ben Elliston devised a system of cron jobs, multiple repositories, and a database to "automatically maintain a repository of code that always passes all the tests". This approach, later dubbed the "Not Rocket Science Rule of Software Engineering," kept a known-good code branch for developers and customers, preventing the headaches of broken main builds.
Fast forward to 2013: Graydon Hoare (creator of the Rust language) faced a similar challenge as Rust's contributor base grew. Remembering Elliston's rule, Hoare implemented a small bot named Bors to enforce it. Bors integrated with Rust's build farm and GitHub: it would monitor pull requests, wait for a reviewer's "approve" command, merge the PR into a temporary branch, and run the full test suite. If tests passed, Bors would fast-forward the main branch to that tested merge commit; if not, it would report the failure and leave the main branch untouched. This ensured that Rust's master branch was always green (always passing tests). The motivation was to avoid "merge skew," where changes appear compatible when reviewed in isolation but break once merged into an updated main. (A classic example of merge skew is two PRs that individually pass tests – one renames a function, and another adds a call to the old name, resulting in a broken main after sequential merges). By "testing it first, then promoting it" to main, Bors kept Rust's primary branch stable without human intervention to update or revert commits.
Rust's experience proved the concept's value. As Hoare noted, the approach "is not rocket science" – it's just tedious to do manually, hence ripe for automation. Bors' success meant that by 2014 the Rust and Mozilla Servo projects were using such bots to gate all merges on tests. However, Bors itself was a quick script, and the need for a more extensible solution soon became apparent.
Rust's Homu and the Rise of Merge Bots
... continue reading