What Is a Merge Queue?
A merge queue is a Git host feature that tests each pull request against the latest main branch, and against the pull requests already ahead of it, before the change merges. The queue exists because two approved PRs can each pass CI on an older main, then break when they land one after the other.
A GitHub merge queue, and GitLab’s equivalent merge trains, serialize that landing. In 2026, the queue also has to deal with agent-opened pull requests: stale approvals, stacks of related changes, and a green suite that may not mean the change is ready to enter the line.
Merge queues in 2026: the line at the end got longer
At the start of 2026, a merge queue was a scaling feature for busy repositories: keep main green by retesting each change against whatever would already be ahead of it.
As agents opened more pull requests, more work arrived at that line, including stacks that belong together and updates that landed after a person had already approved.
A merge queue is good at one job: merging in an order that CI has actually seen. A merge queue is not a review, and it is not an approval policy.
If a change enters the queue on a stale approval, or on tests the agent could edit, the queue will happily try to land a problem in the right order.
Our view: a merge queue should be the last line, not the only check, especially when agents are opening the pull requests.
2026 merge queue highlights
- The 2026 Faros AI Engineering Report found that higher AI adoption came with 33.7% more task throughput per developer and a 441.5% rise in median time in review (2026, Faros). More approved work arriving, more slowly, is exactly the pressure a merge queue then has to absorb.
- Itamar Friedman described agent work arriving as stacks of pull requests across components and repositories, leaving people to work out how those PRs relate before anything can land (October 1, 2026, Qodo).
- Trunk-based development stays the usual reason to run a merge queue: many small changes trying to enter one main branch without breaking it.
What merge queues need next: the 2027 outlook
- Expect queues to remain the right way to protect main when many changes land in a short window.
- Expect teams to treat "eligible for the queue" as a higher bar than "the tests the agent can see have passed."
- Expect stacked or related pull requests to need a review of combined risk before they are queued as if they were independent.
- Our verdict: the queue should merge only what has already been independently reviewed, and what still matches that review after the latest commit.
- Qodo has Agentic PR Review that reviews a pull request before it is ready to enter a merge queue, so the quality check happens upstream of the line.
- Qodo has Review Standards (Beta) that apply organization rules once Rule enforcement (Beta) is on, so a change is not queued on a green build alone.
How a merge queue works
- A pull request is approved and passes the required checks. The Git host’s branch protection or approval rules decide when the change is eligible. See pull request approval.
- The change joins the queue. It sits behind the pull requests that are already waiting.
- The host builds a merge group. The PR is tested against the latest main plus the changes ahead of it, rather than only against the base the author branched from.
- CI runs on that group. If the group fails, the PR is usually dropped or sent back, and the next group is tried.
- A passing group merges into main. The next PR in the queue is tested against the new main.
On GitHub, that feature is the merge queue, and CI can subscribe to a merge_group event so the tests run on the group, rather than only on the original branch. On GitLab, the same idea is called merge trains.
GitHub merge queue vs GitLab merge trains
| GitHub merge queue | GitLab merge trains | |
|---|---|---|
| Host name | Merge queue | Merge trains |
| Job | Retest each PR against main plus the PRs ahead, then merge | The same job, on merge requests |
| Typical trigger | A PR that is approved and has passed required checks | A merge request that is set to merge when the pipeline succeeds |
| What it does not do | Review the change, or decide who should approve it | Review the change, or decide who should approve it |
Third-party queue products exist as well. The article stays on the host feature and on what should happen before a change is eligible to join.
Why agent pull requests stress a merge queue
Agent-opened pull requests create three stresses a queue was not designed to solve on its own:
- Stale approvals. An agent can push a new commit after a person approved. If the host does not dismiss that approval, the PR can enter the queue on an old sign-off.
- Related stacks. Several PRs for one feature can pass alone and still break once they land, or can be queued in an order that does not match how they should be reviewed.
- A green suite that is not evidence. If the agent could edit the tests, a pass is not a sufficient ticket into the queue. See reward hacking.
The queue will still do its job: test the merge order. The queue will not notice that the change should not have been eligible.
Qodo’s take: review the change before it joins the queue
Qodo is not a merge queue. Qodo does not build merge groups, run the queue’s CI or merge the change.
Qodo is the best AI code review platform to put upstream of a merge queue because Qodo reviews the pull request, and can apply the team’s rules, before a person marks the change as ready to enter the line.
Qodo no longer offers test generation; it focuses on AI code review and code governance.
The shared outcome is agent code merged sooner, with fewer rollbacks.
Enterprise engineering teams get independent findings, and the same organization rules, on every pull request that will later sit in a GitHub merge queue or a GitLab merge train, once Rule enforcement (Beta) is on.
High-velocity teams get that review as soon as the PR is opened, so a change is not waiting in the queue to fail a check that could have been caught earlier, and a person can still refuse to enqueue a high-impact stack.
Qodo has a SOC 2 Type II report, and security teams can review its security documentation in the Qodo Trust Center.
Independent review before the change is eligible
Qodo’s Agentic PR Review runs specialist agents and a judge agent on the pull request. Once Rule enforcement (Beta) is on, Qodo also applies Review Standards on GitHub, GitLab, Bitbucket Cloud and Azure DevOps. Qodo’s findings are advisory. The Git host still decides when a change may enter the queue and when it may merge.
Combined risk for stacks that touch more than one repository
Qodo has a Software Map (Beta) that shows repository relationships and downstream impact. When several agent PRs belong to one feature, that map is how a person judges combined risk before those PRs are queued as if they were unrelated.
Qodo example: the queue was landing already-approved problems
Context: an organization like a platform team using a GitHub merge queue on a busy main branch, with coding agents opening follow-up commits after a first review.
Problem: pull requests entered the queue on an old approval, or on a suite the agent had just tightened, and the queue only rediscovered the problem when the merge group failed, or after a landing.
How Qodo helped: Qodo reviewed each pull request, including later commits that triggered a new review, and applied organization rules once Rule enforcement was on. People used the findings, and the Software Map (Beta) view of related repositories, to decide whether a change was actually ready to enqueue.
Outcome: reviewers can see independent findings before a change joins the queue, and the GitHub merge queue still does the job of retesting merge order on main.
Ways to land changes on a busy main branch
| Approach | What it decides | Limit | Best for |
|---|---|---|---|
| Merge when CI on the branch is green | Whether this branch passed, alone | Misses conflicts with PRs that will land first | Low-traffic repositories |
| GitHub merge queue or GitLab merge trains | Whether the PR still passes against main plus the PRs ahead | Not a review, and not an approval policy | Busy trunk-based repositories |
| Independent review, then the queue | Whether the change should be eligible, then whether the merge order holds | The review tool does not run the queue | Agent-written PRs entering a busy main |
| Qodo | Independent review and organization rules before a PR is treated as ready to enqueue | Not a merge queue; does not merge or run merge-group CI | Teams that already have a host queue and need a quality check upstream |
Qodo features in this table were checked against Qodo’s documentation as of November 10, 2026.
FAQ
Qodo does not replace a merge queue. Qodo does not build merge groups, run merge-group CI or merge pull requests. Qodo reviews the change, and can apply the team’s rules, before a person treats the pull request as ready to enter a GitHub merge queue or a GitLab merge train.
Branch protection decides what must be true before a change is eligible to merge: required reviewers, required checks, signed commits and similar rules. A merge queue takes eligible pull requests and retests them, in order, against the latest main plus the PRs ahead, then merges a passing group.
Each pull request may have passed CI on an older main. Once the first one lands, the second is merging into a different codebase than the one it was tested against. A merge queue retests that second change against the new main, and against any other PRs already ahead of it.
A merge train is GitLab’s name for the same idea as a GitHub merge queue: merge requests are tested in a line against the latest target branch plus the changes ahead, then merged if that combined pipeline passes.
A merge queue will try to land anything that is eligible under the host’s rules. Agent-written changes still need an independent review, a current approval after the latest commit, and a hold on high-impact stacks, before they are treated as eligible. The queue is the last line, not the only check.