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

To build a more general tool, Rust contributor Barosl Lee created Homu as a reimplementation and extension of the original Bors bot. Homu was designed to be generic (not Rust-specific) and easier for others to adopt. It implemented the same core idea: maintain a tested integration branch (often called "auto") that includes pending PRs, and only fast-forward main to auto when tests on auto pass. In practice, Homu reversed the usual merge process: instead of merging a PR then testing, it tested the PR before it landed on main by temporarily combining it with the up-to-date main branch. This ensured that "the main branch is always a copy of auto that passed all tests, processing approved PRs one at a time in order.

Homu was open source and quickly became integral to Rust's workflow (Rust's own Homu instance was named "bors"). In 2015, Barosl even launched Homu as a service (homu.io), making it easy for other open-source projects to use a hosted merge queue bot. This service gained users in various communities, demonstrating a broader demand for maintaining green main branches. Homu's design was language-agnostic, so projects beyond Rust/Servo could adopt it with their CI systems.

However, by around 2018, the original Homu service began to stagnate. The maintainer stopped updating it, the web frontend's source was lost, and eventually the homu.io domain expired. Some projects (like Rust itself) forked and maintained their own Homu instances, but there was clearly room for a modern replacement. This set the stage for the next evolution of merge queue tools.

Bors-NG: Modern Successor to Homu

Enter Bors-NG (Bors "Next Generation"), created by Michael Howell. Bors-NG was a complete open-source replacement for Homu, first released around 2017. It was built to be faster, more user-friendly, and easier to host, while preserving the same core idea of tested-then-merged pull requests. Unlike homu.io, Bors-NG had no closed-source components – the public instance at app.bors.tech ran the same code that anyone could self-host.

Bors-NG quickly became popular, especially for teams on GitHub that needed a merge queue before GitHub offered any native solution. Many saw it as the "spiritual successor to Homu, the original Rust merge bot". It integrated with GitHub pull requests and CI services, allowing maintainers to use the familiar bors r+ command to enqueue PRs for merging once tests pass. For years, this combo of Bors-NG + CI filled a critical gap, giving projects large and small a way to avoid merge skew and keep their main branch healthy.

Notably, the Kubernetes project developed a similar concept in parallel – their Prow/Tide system – and other communities like OpenStack had long used a gating bot (Zuul) for Gerrit. These all share the same philosophy pioneered by Bors. Merge queues became recognized as best practice for high-velocity projects where broken merges are unacceptable.

By 2023, however, the landscape changed: GitHub announced its own merge queue feature (more on that later). The author of Bors-NG announced the public Bors-NG service would be deprecated in favor of GitHub’s native Merge Queue. While Bors-NG remains open source for self-hosters, the availability of an official tool signaled a shift. It was a full-circle moment – a concept that started as a community hack had become mainstream enough for GitHub itself to support it out-of-the-box.

Industry Solutions: Bulldozer, Mergify, and Kodiak

In parallel to the Rust community's bots, other engineers and companies were solving the same problem, often "scratching their own itch." This gave rise to several notable merge automation tools in the late 2010s:

• Bulldozer (2017): Developers at Palantir created Bulldozer as a GitHub App to automate merging and updating PRs. Palantir open-sourced the tool, which could be self-hosted or installed on repos. Bulldozer automatically merges pull requests when all required checks and reviews are satisfied, and it can also auto-update PR branches to keep them in sync with the base branch. Essentially, it removes the manual "update and merge" drudgery in a fast-moving trunk-based development workflow. An example use case is at ACV Auctions, where engineers adopted Palantir's Bulldozer to ensure everyone's feature branch stays up-to-date with main and merges immediately once tests pass (They noted that for public GitHub usage, Bulldozer could be run as a custom instance, as it wasn't officially listed on the marketplace at the time)

• Mergify (2018): That's us! Frustration with manual PR management led Julien Danjou and Mehdi Abaakouk to build a small merge automation tool for their team in 2018. That side project struck a chord and soon evolved into Mergify, a full-fledged SaaS product and company. Mergify introduced features to queue, update, and merge PRs with flexible rules, effectively bringing merge queues to any GitHub repository via a cloud service. The founders (long-time open source contributors) initially open-sourced Mergify's code and offered it free for OSS projects. Over the years, Mergify became a popular "CI companion" for teams worldwide, offering advanced queue configurations, priority rules, batch merging, and more on top of GitHub's API. It was essentially "merge queue as a service," well before GitHub's native feature. (As an aside, Mergify's engine was eventually made closed-source in 2022 as the business matured, but it continues to serve thousands of developers.)

• Kodiak (2019): In early 2019, developer Christopher Blump faced constant delays from having to rebase and update PRs in a busy repo with an always-green main policy. He evaluated existing tools like Bulldozer and others, even contributing a patch, but found "none of the existing projects… solved the problem of efficiently updating and merging pull requests." So during his college finals in May 2019, he built the first version of Kodiak. Kodiak is an open-source GitHub App that automates the “update with latest main and merge if tests pass" dance. It introduced a proper queue to merge PRs in order, eliminating the race condition when multiple developers try to merge at once. The initial version was basic (queue in memory, no persistent state) but solved the pain point. By that summer, Kodiak’s usefulness caught on – it got a considerable boost when Vercel’s CEO tweeted about using it to auto-merge and deploy changes. This endorsement in July 2019 brought a wave of adopters, and Kodiak rapidly grew via word-of-mouth in the open-source community. Kodiak added features like configuration files, persistent queues, and GitHub checks for transparency. It became another popular option for teams wanting a hosted merge bot, though it is not actively maintained anymore.

These tools all shared a common purpose: to safely remove human bottlenecks in merging PRs. They watched for PRs meeting defined conditions (CI passes, approvals present, specific labels, etc.) and then automatically merged them in a controlled way. Many could also keep branches rebased or updated to prevent stale merges. In effect, they implemented merge queues or merge trains outside of the platform – a testament to how universal the need had become by 2018–2019.

It's worth noting that GitLab users were also early to this idea: GitLab introduced an official Merge Trains feature in mid-2019 (GitLab Premium 12.0) to queue merge requests and run "pipelines for merge results" on each in sequence. This was GitLab's integrated solution to guarantee that each MR is tested with all prior changes before landing, much like Bors/Homu's approach. Merge Trains made it easy to auto-merge a series of MRs without breaking the target branch, and even supported batching multiple MR commits into one pipeline run for efficiency. In other words, by 2019 the concept of merge queues had leapt from niche bots to built-in VCS platform features – at least on GitLab.

Internal Merge Queues in Tech Giants

Large-scale organizations soon recognized that hand-rolling merge queues was often the only way to keep their main branches stable amid heavy developer activity. Uber, for instance, built a system called SubmitQueue to verify and land changes in their monorepo, reducing CI wait times by 74% and dramatically improving merge throughput while keeping the mainline green. Shopify, working on a massive Rails-based monolith, added a merge queue into their deployment tool, Shipit, to prevent accidental merges during backlog surges and maintain pipeline reliability. Similarly, Strava created an internal tool dubbed Butler, a CI-integrated merge queue that enforces orderly merging for their fast-moving engineering teams.

At Shopify, developers gave positive feedback early on: “By getting automation involved earlier in the pipeline, we were able to take some of the load off our developers, make them happier, and more productive.” In fact, over 90% of pull requests to Shopify’s core application now use the Shipit Merge Queue. This demonstrates how merge queues aren’t just technical enablers—they improve engineering experience at scale.

Mainstream Adoption: GitHub's Merge Queue

Given the success of these systems, it was perhaps only a matter of time before GitHub provided native support. Historically, GitHub's stance was more manual: they added a basic "Auto-merge" option in late 2020 that lets a PR merge after checks pass. However, that still didn't handle multiple PRs interacting or ensure rebasing. The true paradigm shift came in 2022–2023.

GitHub’s own Merge Queue wasn’t born from product planning—it was born from internal necessity. By 2016, GitHub engineers were merging nearly 1,000 pull requests per month into their expansive monorepo. The resulting chaos mandated a smarter system. What emerged was the concept of a "train" — a bundle of PRs tested, deployed, and merged together under human orchestration. This was a precursor to today's fully automated queues. An internal shift began in 2020, when multiple teams pooled efforts to streamline PR merging across internal projects. By mid-2021, GitHub piloted a merge queue in smaller repos and, by 2023, had rolled out an internal system powering thousands of merges monthly—cutting average wait times by 33% and calling the Merge Queue "one of the best quality-of-life improvements" they'd seen

Then, GitHub decided to release its internal merge queue as part of its product. They began experimenting with a first-party Pull Request Merge Queue (PRMQ). After a closed beta, in February 2023, GitHub released its merge queue feature in public beta, and by July 2023, it was generally available.

GitHub's Merge Queue closely mirrors the principles established by Bors and others: it maintains a queue of PRs waiting to merge. It ensures each PR is tested in a merged state (often by creating a temporary merge branch for the PR and running CI) before it lands on the base branch. In effect, it automates the formerly tedious process of constantly rebasing or updating PRs and serializing their merges. As GitHub's announcement put it, developers used to have to update their feature branches one-by-one and re-run CI to avoid breaking main; "Merge Queue automates this process" by queuing PRs and testing them with any earlier queued changes. The result is higher velocity and confidence that incompatible changes never break the default branch.

The introduction of GitHub's own merge queue was a watershed moment. It validated the approach pioneered by community tools and brought it to a much broader audience. Organizations on GitHub Enterprise Cloud or public open-source projects can now simply toggle on a merge queue in settings, without needing an external bot. The impact was immediately felt: maintainers of Bors-NG announced the phase-out of their hosted service in favor of GitHub's queue, and guidelines for migrating from Bors to GH Merge Queue emerged. Essentially, the ecosystem came full circle – what started as a custom script to enforce an "always-green" rule evolved into a standard platform feature.

It's important to note that GitHub's initial implementation has some differences in workflow. For example, GH Merge Queue uses a two-phase testing approach (one run on the PR itself, and a second run after queueing when merged into a temporary branch) whereas tools like Bors performed a single integrated test cycle. There are also limitations: among others, GitHub's queue is FIFO only (no priority reordering) and lacks batch merging capabilities. Third-party services like Mergify have pointed out these gaps quickly, since their products offer more advanced queue configurations (multiple queues, priority rules, batching to merge several PRs at once, etc.). In fact, even after GitHub's native queue launch, some teams continued to use or switch to tools like Mergify or others for more flexibility. Nonetheless, the core need is now officially recognized and supported by GitHub, a significant milestone in the history of merge queues.

Conclusion: From Niche Scripts to Essential Workflow

In a little over a decade, merge queue systems have gone from an obscure hack to an essential part of modern software delivery. The progression tells a story of increasing scale and quality demands:

• Early 2010s: Only very large or risk-averse projects (like Rust, Servo, or OpenStack) felt the pain strongly enough to build bespoke solutions (Bors, Homu, Zuul) to guarantee unbreakable main branches. These were novel, community-driven efforts born out of necessity – enforcing the "always passes all tests" rule that was known but rarely automated.

• Late 2010s: As continuous integration became ubiquitous and teams adopted trunk-based development, the merge skew problem became more common across the industry. This spurred a wave of tools – some open-source, some commercial – to automate PR merging (Bulldozer, Mergify, Kodiak, and others). They enabled even smaller teams to achieve what only giants could before: continuously integrating code without constantly babysitting CI or worrying about conflicting changes. The fact that a lone developer could write Kodiak in a weekend to solve his team's annoyance, and that it immediately found a user base, speaks to how widespread the need had become.

• 2020s: Merge queues became mainstream best practice. Platform support (GitLab's Merge Trains, GitHub's Merge Queue) lowered the barrier to adoption. Today, even teams that never heard of "bors" or "homu" are benefiting from the lessons those tools taught. On GitHub, you can simply enable a branch protection that uses a merge queue, and achieve the same guarantee that “the main branch is never broken by incompatible changes.” The ecosystem around merge automation is still evolving – with third-party services pushing the envelope on features – but the fundamental approach is here to stay.

In an academic sense, it's fascinating how a principle from the early 2000s configuration management became a pillar of modern DevOps. The story of merge queue systems is one of increasing automation to support software quality at scale. By eliminating the integration risk of each incremental change, developers can move faster without fear.

What began as Graydon Hoare's small Rust bot named after a knight (Bors) has grown into a standard tool in software teams' arsenal, ensuring that code integration is "not rocket science" but a well-engineered process. Merge queues have evolved from niche hacks into an industry standard—because as PR velocity increased, they weren't a luxury, they became an operational necessity.