Do you have engineers that open pull requests and then go ahead and approve it themselves? That’s a huge red flag! With no one reviewing the work, and the pull request being sent to production, your team is setting itself up for trouble.
As a rule, most companies do not let developers merge their own code. The habit of self-merging bypasses the human review process. This means your codebase will become more prone to the introduction of bugs.
Think of it this way: if a piece of code is important enough to put into the main branch, it’s definitely worth having someone review it.
Recognizing Self-Merging Habits
This dangerous pattern is pretty easy to spot as the submitter and reviewer are the same person/people.
I’ve Spotted Team Members Self-Merging. Now What?
If your organization has already built systems to prevent self-merging pull requests, you’ll likely never have to worry about this habit. However, an enforced review is a common requirement among organizations that fall under certain regulatory compliance (for example, fintech companies). This is because self-merging can represent a substantial security risk to the company. Therefore, if you spot it, you need to act fast.
Self-Merging and Compliance Issues
If your organization doesn’t have compliance regulations to worry about, that doesn’t mean you should ignore the problem. As a manager, you need to be aware of how reviews unfold, so it’s crucial to go ahead and review them – even after they have been merged. This will help ensure that any bugs or other issues that may have gotten through on a self-merge are caught immediately and not buried.
Get QA and Senior Devs Involved
You likely can loop in QA and let them know they should take a closer look at a trivial commit. However, if the pull request was substantial, try to walk it back (if possible) and do a proper code review.
If it’s not already one, make it a best practice to get unreviewed pull requests down to 0% (or close to 0%). Pull aside developers who have made self-merging an ongoing habit. Have a informal one-on-one with them about the ‘why’ behind the rules against self-merging. They may not be aware of the compliance they are violating or how self-merging can lead to bugs or other more extensive problems down the line. It will likely help if you can recruit more senior developers on the team to adhere to the rule and make it a habit. Their leadership on this – especially with more junior developers or new hires – can help ensure self-merging comes to an end.
In the future, make expectations clear across the team that self-merging is not allowed – even on small commits.
Conclusion
By being clear about the issues (and dangers) surrounding self-merging, your team members will begin to understand why self-merging is a bad idea and could be a substantial compliance red flag. Be sure to reinforce the importance of avoiding such habits and avoid letting it slide for smaller commits – it can be a slippery slope and lead to developers mistakenly believing that the behavior isn’t that bad and could introduce problems into the underlying code.
Bitband is here to help you integrate your Git platforms with Jira. Check out all of our great highly-rated plugins for Bitbucket, GitHub, Gitlab (and more) on the Atlassian marketplace.
Want more Bitband insights? Check out:
