Deterministic ordering + conflict detection

Deterministic ordering means the merge queue processes PRs in a defined, predictable sequence rather than in arbitrary arrival order. Conflict detection means the system proactively identifies PRs that will conflict before they enter the queue, rather than discovering conflicts mid-queue and forcing a disruptive reset. Together, these two capabilities transform a basic merge queue into a reliable, high-throughput merge pipeline that can process hundreds of PRs per day without operational surprises.

In a basic merge queue (L2), PRs enter in FIFO order and are tested sequentially. This works but has inefficiencies: large or slow-testing PRs block all subsequent PRs in the queue, and conflict detection only happens when a PR enters the queue and the rebase fails. At L3, deterministic ordering adds priority lanes and batch scheduling to the queue. Conflict detection adds pre-queue analysis: before a PR is even added to the queue, the system checks whether it will conflict with currently queued PRs and alerts the author.

Deterministic ordering is critical for AI-assisted teams because agents produce PRs continuously and often in overlapping areas of the codebase. Without deterministic ordering, the queue can become pathological: a large agent PR that takes 20 minutes to test blocks 15 smaller PRs. With priority-based ordering, small, fast-testing PRs can be promoted ahead of large ones, maximizing throughput while maintaining the conflict-prevention guarantee.

Mergify implements this through its queue system: PRs can be assigned to named queues with different priority and batch settings. Trunk.io's merge queue has explicit priority lanes. GitHub's native queue supports batching but has limited ordering control - teams that need sophisticated ordering typically move to Mergify or Trunk at L3.

• Prevents queue starvation - without ordering rules, a slow PR blocks all subsequent PRs; deterministic ordering ensures fast PRs aren't held up by slow ones
• Dramatically reduces "queue reset" overhead - when a conflict is detected mid-queue (after CI has already run), the queue must drain and restart; pre-queue conflict detection catches this before any CI has run, saving compute and time
• Enables predictable merge schedules - with deterministic ordering, teams can make reliable predictions about when a queued PR will merge; this matters for release planning and cross-team coordination
• Required for batch CI optimization - batching multiple PRs into a single CI run (major throughput optimization) requires knowing that the batched PRs are compatible; conflict detection is the prerequisite for safe batching
• Reduces developer anxiety about queue position - when ordering is deterministic and visible, developers understand why their PR is at position 7 in the queue and what will happen if the PR ahead of them fails; opacity creates frustration

1. Audit your current queue failures - before adding complexity, understand why your current merge queue fails. Pull the last 30 days of queue events: how many PRs were removed from the queue due to conflicts? How many caused queue resets? This baseline tells you how much the improvements will matter.
2. Implement Mergify with named queues - Mergify supports multiple named queues with different CI requirements and merge strategies. Create at minimum two queues: fast for small, low-risk PRs (docs, tests, minor fixes) and standard for feature and infrastructure PRs. Assign PRs to queues via labels.
3. Enable conflict detection at PR open time - add a GitHub Action or Mergify rule that checks for conflicts between the new PR and all currently open PRs when a PR is opened. Tools like code-freeze and custom Actions can detect file-level overlaps. Add a potential-conflict label and notify the author.
4. Set queue priority rules - in your Mergify configuration, define priority ordering: approved PRs ahead of pending-review PRs, small diffs ahead of large diffs, certain teams' PRs get priority lanes (e.g., on-call engineers fixing incidents jump the queue). These rules should reflect your team's actual priorities.
5. Implement batch CI for the fast queue - once you have a stable fast queue, enable batch merging: combine 3-5 fast-queue PRs into a single CI run. If the batch passes, all PRs in the batch merge together. If it fails, bisect to find the culprit. This can increase throughput by 3-5x for small PRs.
6. Monitor and tune regularly - queue performance degrades as the codebase and team grow. Review queue metrics monthly: average wait time by queue, batch success rate, conflict detection accuracy. Tune queue rules to maintain target wait times.

Conflict detection that cries wolf. A conflict detection system that flags 30% of PRs as "potential conflict" when only 5% actually conflict trains developers to ignore the alert. Tune your conflict detection to have high precision: only flag conflicts that will actually block merging. File-level overlap detection over-fires; add heuristics (both PRs modify the same function, not just the same file) for better precision.

Priority queues that create starvation. If the "fast" queue has unlimited capacity and always has PRs, the "standard" queue PRs never merge. This is a priority inversion problem. Cap the fast queue throughput advantage: "fast queue PRs get priority, but standard queue PRs must merge at least once every N queue cycles." Starvation prevention is a basic scheduling requirement.

Batching PRs that shouldn't be batched. Batch CI works because CI is faster when running fewer times. But if batched PRs have side effects that interact (both modify a singleton, both write to the same test fixture) batching can cause failures that would not occur when tested individually. Restrict batching to PRs that touch non-overlapping file paths.

Not accounting for queue ordering in release notes. When multiple PRs are queued and batch-merged, they appear in the git history in merge order, not authoring order. This can make release notes and changelogs confusing. Ensure your changelog generation uses the PR metadata (title, description) rather than commit order.

Opaque queue state. Developers need to see queue state to understand why their PR hasn't merged. A queue that's a black box generates support requests and frustration. Implement a public queue dashboard: current queue depth, each PR's position, estimated wait time, current CI status. This is a 2-3 hour implementation with significant developer experience payoff.