Branch protection is an important part of making sure accidents and mistakes don’t happen in your GitHub repository. They enforce rules that anyone who wants to push commits or merge pull requests in your repository must follow.

Why is Branch Protection Necessary?

Branch protection is all about preventing unwanted actions. You can set rules to require pull request reviews, require tests to be completed before merging, or requiring signed commits to verify authenticity.

By default, branch protection will disable force pushes and prevent branches from being deleted. These are two things that you basically never want to have happen regularly, and never without the express consent of someone who can make an exception and disable the branch protection.

This is good for security, especially in larger projects or open source repositories where maintainers want to enforce a particular submission and approval process for new changes. Branches can also be locked down entirely for non-admins, which can be used to apply additional authorization to release/production branches.

Branch protection, by default, won’t apply to admins. You can also give people specific permission allowing them to bypass it. If you don’t want admins or anyone else being able to bypass certain rules, you can disable this for each rule.

Branch protection is available for free for public repositories, but is not available for private repositories without GitHub Team or Enterprise.

What Do GitHub’s Branch Protection Rules Do?

There are quite a few settings you can enable for branch protection, and they all do different things. Here are some of the most useful ones:

  • “Require pull request reviews before merging” will not allow PRs to be merged into protected branches until one or more people with permission have approved the request. This is especially useful for preventing a single person from merging a PR on their own.
  • “Require conversation resolution” will ensure that only closed and finalized PRs are allowed to be merged.
  • “Require status checks before merging” will integrate with your CI pipeline to run tests on new commits to verify that they don’t break anything. GitHub even has a commit status API that you can use for external integration.
  • “Require deployments to succeed” is typically used to ensure that builds are deployed properly to staging environments before being merged.
  • “Require linear history” prevents merge commits from being pushed to the branch, which requires merges to be squash or rebase merges. Linear commit history is preferable by many teams as it makes tracking down and rolling back versions much easier.
  • “Require signed commits” will enforce commits to be GPG signed, verifying that they were created with the user’s private key and not authored by an attacker with GitHub access.

On top of all of this, you can also manage permissions directly to decide who can push to the branch. For example, it’s typical for release branches to have extra restrictions so that any random intern can’t accidentally push to production.

You can also lock branches entirely, like in the case of upstream branches that shouldn’t change.

Additionally, while admins have the ability to bypass these rules by default, you can also turn that off, making sure nobody in your repository can violate the rules without the rules being disabled.

How to Set Up GitHub Branch Protection Rules

Branch protection rules are set in the repository settings. Click the settings button for your repository, and then click “Branch Protection.”

You must set a filter for the branch protection rule. You can just set it to the name of a specific branch, such as “main”, or you can use wildcards to target multiple branches at once.

An unbounded wildcard “*” will apply to all branches, and multiple branch protection rules can stack on top of each other. However, you cannot have two rules with the same filter.

Next, you’ll have the option to configure each branch protection setting. By default, only force pushes and deletions are disabled, but you can enable any of the check boxes here to turn on other things you want.

One thing that you’ll want turned on most of the time is the rule preventing admins from bypassing the rules.

Then, you can enable the rule, though you will have to re-authenticate with the GitHub mobile app since changing branch protection rules is a restricted action. You can test if it’s enabled by attempting to force push—your Git client should show an error.

Leave a Reply

Your email address will not be published. Required fields are marked *