Merging is a manual act

Merging is a manual act: someone clicks the button on every change. A developer opens a pull request, waits for whatever the team considers sufficient, and then merges it themselves at a moment of their own choosing. There is no policy enforcement, no automation, and no queue. The rules about when a change may land live in the heads and habits of the team rather than in the tooling.

This guide is about how a change flows, not about whether it is any good. Forming the verdict - reading the diff, judging correctness, deciding the change meets the bar - belongs to Code Review & Quality, and everything below assumes that verdict exists in some form. The question here is what happens next: who acts on it, when, in what order, and what the system does if two people act at once. At this level the answer to all four is "a human, whenever they get round to it".

At L1 this is not just a tooling choice - it reflects an underlying assumption that the act of merging is itself a judgement call, distinct from the judgement already made about the code. Approval and merge are two separate human decisions, separated by an arbitrary gap, and the second one carries information nobody has written down: is main stable right now, is it too close to the release, did anything else land in the meantime. This model works when volume is low (under 10 pull requests a day), the team is small, and everyone can hold the state of main in their head.

The hidden cost of this model only becomes visible under load. When a team starts using AI agents to produce code - even just developers using Copilot or Claude Code - volume rises faster than anyone's willingness to keep clicking. A team that comfortably handled 5-8 pull requests a day starts seeing 20-30, and the manual merge becomes a wall independent of review: changes that everybody agrees are fine sit approved and unmerged, sometimes for days. Worse, the changes that do land were each tested against a main that has since moved, because nothing verifies a change against the state it will actually merge into.

This is the state to understand and escape, not to optimise. Improving the review itself is worthwhile and is covered in its own area, but it does not address this bottleneck: a perfectly reviewed change still waits for a human to click. The goal here is to map what is manual about the flow, work out why, and separate the part that genuinely needs a human decision (shipping authority on a risky change, timing around a release) from the part that is only manual because nobody has written the rule down.

• Baseline diagnosis - most teams don't realize how much of their merge process is manual by default rather than by design; mapping it explicitly reveals the automation opportunities
• Approved-but-unmerged becomes the real backlog - the visible queue is changes awaiting a verdict, but under agent load the larger and quieter pile is changes that already have one and are waiting for someone to act on it
• Inconsistent enforcement - when the conditions for merging live in people's heads rather than in tooling, what lands depends on who happened to click and on what day; policy drift is invisible until something breaks main
• No throughput ceiling visibility - without measuring how many changes move through the system, teams do not know they have hit the wall until delivery dates start slipping
• Nothing is tested in the state it lands in - manual merges are serialised only by luck, so two independently green changes can combine into a broken main, and the breakage is discovered by whoever pulls next
• Foundation for automation - understanding the current manual process in detail is the prerequisite for automating it; you can't automate what you haven't mapped

1. Map your current process explicitly - write down every step from "PR opened" to "code in main." Who does what? What triggers each step? Where do PRs wait? How long does each wait typically take? This map will reveal the bottlenecks you didn't know existed.
2. Measure baseline PR cycle time - use GitHub Insights, LinearB, or a simple script to pull average time from PR open to merged for the last 30 days. Break it down: time to first review, time to approval, time from approval to merge. This is your L1 baseline.
3. Count PRs per day - how many PRs does your team merge on a typical day? A typical week? Track this number. It will tell you when you've hit the manual process ceiling.
4. Identify what the reviewers actually check - interview your reviewers: what do they look for? How much of it is mechanical (formatting, naming, test coverage) versus judgment (architecture, correctness, security)? The mechanical checks are automation candidates.
5. Define your merge criteria explicitly - write down what "approved and ready to merge" actually means for your team. This is the first step toward codifying it as policy. Even a simple checklist (CI passes, one approval, no unresolved comments) is progress.
6. Pick one manual step to eliminate - don't try to automate everything at once. Start with the most mechanical step: for most teams, this is "wait for CI to pass before merging." Add a branch protection rule that requires CI green before the merge button is enabled.

Treating every change as equally risky on the way in. A CSS tweak and a schema migration take the same path to main and wait behind the same people. Routing all changes identically regardless of blast radius means the risky ones get no extra care and the trivial ones get no less. Segmenting changes by risk is what later lets different classes flow at different speeds, and it is worth starting the segmentation long before there is any automation to apply it to.

Fixing the verdict when the problem is the flow. Teams at L1 often respond to a growing backlog by working on review itself - better checklists, more thorough comments - when the changes are already approved and simply are not moving. Improving how a verdict is reached does nothing for the interval between reaching it and acting on it. Measure the two stages separately before deciding which one to invest in.

No visibility into the queue. PRs waiting for review are often invisible. There's no dashboard, no SLA, no alert when a PR has been waiting more than 4 hours. Without visibility, the queue grows silently until someone notices a feature hasn't shipped in two weeks.

Merging manually without a consistent strategy. Some developers merge with squash, some with rebase, some with merge commits. Inconsistent merge strategies produce a noisy git history that makes debugging, bisecting, and reverting harder. This is a small friction at L1 but compounds significantly as volume grows.

Merging without checking what landed in the meantime. A change that was green three days ago is a claim about a main branch that no longer exists. At L1 nothing re-verifies before the click, so the first sign of a bad combination is a broken build for everyone. Rebasing before merge is the manual version of the fix, and noticing how often it is skipped is what makes the case for a queue later.