Nobody approves their own merge request

In the Git conventions I set up with teams, one line does more work than all the others: nobody approves their own merge request.

The rest of the conventions set up that line. The shared branch is protected, so nobody pushes to it directly. Every change goes through a merge request, including a contribution to a colleague’s branch. A request is accepted when the build passes, the commit messages follow the agreed format and the reviewer’s comments have been addressed. Then someone other than the author approves it, or it is refused.

A merge request approved by its author is a formality, not a review

The author is the worst-placed person to read their own change. They know what the code is meant to do, so they read the intention rather than the lines. The second reader has only the lines, which is exactly what the next maintainer will have.

The rule also changes the conversation. A reviewer who must approve has to understand the change well enough to defend it, so knowledge of that part of the code now lives in two heads. And the author writes for a reader from the start: smaller requests, clearer messages, a description that says why.

The pipeline does not replace that reading. It checks what can be checked: the build, the tests, the quality gate. It cannot say whether the change is the right one, whether it answers the user story or only passes its own tests.

In my view, this line matters more in 2025 than when I first wrote it. The more of the code an assistant writes, the more the second human reader matters. When the first draft comes from a tool, the developer who opens the request is already the first reader of code they did not type. Approving it themselves would leave the change with no reviewer at all.

The rule costs one person a few minutes. Skipping it costs the team the only reading that was not the author’s