auto-merge

Clean pull requests merge themselves. On your rules.

When a change has a clean review, passing tests and matches the spec, there's nothing left for a person to decide. CodeReviewer approves and merges it (squash, merge or rebase). If people disagree, it steps aside.

Start free trial Talk to sales

Bump invoice PDF marginsmerged

auto-merge · squash · policy: clean review + spec match

✓ review: no findings above “minor”
✓ tests: 42 passed
✓ spec: matches “Receipts in the customer portal”
✓ approved & merged 11 minutes after opening

the problem

Good changes wait for a click.

Small, safe pull requests sit for hours because the one person who can merge is in meetings.

Branches fall behind while they wait, pick up conflicts, and need another round of attention.

Blanket auto-merge tools can't tell a trivial change from a risky one, so teams switch them off.

how it works

From trigger to result.

You set the policy

Pick when merging is allowed (a clean review, and optionally a match against the spec) and how it merges.

The PR is reviewed and tested

CodeReviewer reviews the change and runs your tests as usual.

Conflicts are resolved

If the branch has fallen behind, conflicts can be resolved on the branch automatically.

It approves and merges

When every condition holds, the pull request is approved and merged. If not, it waits for a person.

capabilities

What you get.

Policy-driven merging

Merge only pull requests with no significant findings. If you like, only the ones that match a requirement in your spec.

Your merge method

Squash, merge commit or rebase, set per repository to match how your team keeps history.

Merge-conflict resolution

Branches that have drifted behind are brought up to date and their conflicts resolved, so a safe change doesn't stall.

Defers to humans

If people have disputed CodeReviewer's findings on a pull request, it stands down and leaves the decision to them.

Per-PR test pass

Your repo's own tests, or a browser pass against the PR's preview URL, feed into the merge decision.

Permission-controlled

Merging pull requests is a member permission, so admins decide who can turn it on and for which projects.

Why most auto-merge gets switched off

Rule-based auto-merge looks at green checks and nothing else. A green check doesn’t know whether the change touched billing or fixed a typo, so teams either live with the risk or switch the feature off. CodeReviewer looks at more before it merges: a full review of the change against the whole codebase, your test results and, if you want it, a match against the spec your team agreed to build.

Humans stay in charge

Auto-merge is a convenience, not an override. If a reviewer disputes a finding, if a condition isn’t met, or if the policy is off for a repository, the pull request simply waits. CodeReviewer’s review and approval sit on the pull request like any reviewer’s, so anyone can see what it checked before the merge.

faq

Questions, answered.

Isn't auto-merge risky?

Only if it's indiscriminate. CodeReviewer merges only when the review is clean, your conditions are met and nobody has pushed back on its findings. Anything else waits for a person.

Can we limit it to some repositories?

Yes. Auto-merge is configured per repository, and you choose the merge method for each.

What does "spec-gated" mean?

If you track a spec in CodeReviewer, you can require that a pull request matches one of its requirements before it's merged. That way only planned work merges on its own.

How are merge conflicts handled?

CodeReviewer can resolve conflicts on the pull request's branch. The result goes through the same review before any merge.

Give every PR the review it deserves.

Start your 15-day free trial. We onboard a few teams every week.