The Origin Story of Merge Queues

Summary

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 ExperimentsThe 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 m...