·
It defines when an engineer opens a pull request and then approves it him/herself. Heading unreviewed to production!
As a general rule, engineers shouldn’t merge their own code. It easily introduces bugs. If the code is worth putting on the main branch, it is worth having someone review it.
HOW TO RECOGNIZE IT
Self-merging is easy to see because the submitter and the reviewer are the same people.
WHAT TO DO
Many organizations prevent self-merging PRs by configuring their build systems to reject them.
But even in organizations that don’t enforce review, managers should be in the know when these situations do happen.
Reviewing these PRs on a case-by-case basis, even AFTER being merged, will prevent bugs to get buried.
Reviewing these PRs on a case-by-case basis, even AFTER being merged, will prevent bugs to get buried.
Reducing the frequency of unreviewed and self-merged pull requests is a best practice. Unreviewed PRs should be 0%, or close to it.
If engineers are in the habit of self-merging without review, talk with them to ensure that they understand the ‘why’ behind getting the review process or at least clear on expectations.
If they’re more senior, encourage them to follow the best practice of getting code thoroughly reviewed by others, so other engineers will model that behavior.
If engineers are in the habit of self-merging without review, talk with them to ensure that they understand the ‘why’ behind getting the review process or at least clear on expectations.
If they’re more senior, encourage them to follow the best practice of getting code thoroughly reviewed by others, so other engineers will model that behavior.