Version Control is an essential tool in development. It allows changes to be made ‘safely’, without fear of irreversibly changing code.
It isn’t without its risks, though.
Accidents can happen. But how do you also prevent obvious mistakes from being made, avoiding any time-consuming damage control on important branches? GitHub has some built-in tools to help automate these processes.
Where are these fabled settings? In Settings, of course!
There’s a category in the Settings tab of any repository called ‘Branches’. This is what it’ll look like by default:
You can just about see the section we’re interested in – ‘Branch protection rules’.
In this instance, we’re going to click ‘Add rule’.
Configuring Branch Protection
You’ll see the first option is to specify a ‘Branch name pattern’. Pattern, you say? I’ll use Regex then!
No, unfortunately not. Github apparently uses fnmatch for pattern matching, so you’ll want to work off that.
In this example, we’ll use an explicit ‘master’ reference.
These are our protection options, at time of writing:
There’s a lot that can be configured here, depending on how your personal or work environment is configured. ‘Require pull request reviews before merging’ is the key one here though.
As per the above, you can enforce that a PR cannot be merged until a number of approving reviews have been submitted – that is, one user (other than the author) must approve the PR before it can be merged. In teams of at least 4 people, it’s a good idea to have this set to 2 people, minimum.
What if there aren’t 2 other people available? Well, that’s a business decision. It could be argued that mistakes occur under pressure, so this might be the vital part you need to think about.
In addition, it’s a good idea to have approvals ‘dismissed’ if new commits are pushed. If left unticked, an approval could be out-of-date, which would make it a little redundant.
Finally, ‘Require review from Code Owners’ means that at least one review is required from a ‘Code Owner’ – this is another useful feature that I will cover in another post.
‘Require Status Checks’ is useful if you have Jenkins integration in your repositories – you can prevent changes being committed that would break your builds. Going further, SonarQube is a powerful ally in your Pull Requests, adding in the ability to check for Technical Debt or Code Coverage before a PR is able to be merged.
In this example, I’m only going to select these others:
‘Include administrators’ can be problematic on your master branch (or other release branches) if you use Jenkins for releases, so tread with caution. It should be fine for non-release branches.
Let’s see it in action.
Protected Branches in Action
I’ve made a simple change here to the develop branch, and I’ll open the PR to the Master branch.
(Note in the ‘Reviewers’ section it already says “at least 1 approving review is required”)
Once opened, the Pull Request will be blocked from merging until one review has been added.
Now that we’ve seen what we can do, let’s weigh it up.
The Advantages
The default stance on this is that, quite clearly, it is a powerful configuration tool to have available. It will give visibility to your repositories and can not only prevent people pushing directly to Master. Let’s look at the detail of that option again:
When enabled, all commits must be made to a non-protected branch and submitted via a pull request with the required number of approving reviews and no changes requested before it can be merged into a branch that matches this rule.
As all commits must come from a non-protected branch and via a pull request, it means that it helps to enforce good behaviours, such as feature branches.
Integrating some of the additional options, such as ‘Require Status Checks’ is also, where possible, a great way of automating quality. People tend to push back against individuals requesting a certain quality level, or a certain amount of Unit Test coverage – but there’s no reasoning with an automated gate. This means that you can be less vigilant and let GitHub look after your branches.
The Disadvantages
I’m a big fan of Branch Protection, but it can be a bit of a pain when you get to more intricate configurations. If, for example, you rely on SonarQube as a way to police code quality with a ‘Required Status Check’, if SonarQube is having a bad day, it can block your progress.
Equally, if an important fix or release is needed, and it’s at a time when people tend to not be around as much (e.g. Christmas), then you can also be obstructed by simply not having enough reviewers to meet your requirements.
These are, of course, business process gaps at best. As mentioned earlier, would you want code to be merged if SonarQube isn’t working? Or if there aren’t enough developers to review the code? This is perhaps where you can restrict who has administration access, and ensure a repo admin is always available in extreme cases.
The decision is, of course, only yours to make.