GitHub Branch Protection: What It Is and Why It Matters

GitHub offers a great deal of flexibility for more collaborative development among more widely distributed teams. Now, anyone can work together on a single codebase without losing track of other contributors’ progress in relation to their own. However, this flexibility can actually prove to be more of a problem than a solution if left unchecked.

Without proper protection, any branch in your project's codebase could face deletion or alteration that is difficult to reverse. Branch protection provides a fairly simple solution, but your team might not be familiar with it. Read on to learn what branch protection does for your code and why you should likely be using it now.

What is GitHub branch protection?

GitHub branch protection is an essential part of many development projects. Whenever contributors interact with a given codebase on GitHub, it is well-defined branch protection that prevents them from negatively impacting it.

Accidents can happen with any project, and GitHub branch protection puts safeguards in place to ensure code is kept out of harm's way during otherwise routine deletions, merges, and review processes. Without GitHub branch protection, the above and many other factors can wreak havoc on your codebase, costing your entire team many hours of dedicated work in the process. GitHub's flexibility makes it possible for you to force pull requests through a series of checks (both automated and manual), with the help of your choice of tooling, before they are actually merged into protected branches.

What GitHub protected branches do

GitHub protected branches are an excellent solution for project leaders looking to keep tabs on top-priority code changes and updates without discouraging distributed development teams from freely contributing code. Team leaders simply set specific rules for protected branches.

These can include any of the following:

• Making reviews mandatory before pull requests can be merged. Requiring pull requests be reviewed any number of times—and by specific team members or code owners—can help stop unfinished code from marring your main branch. Coupled with refined review dismissal options, this simple rule is great for emphasizing an appropriate workflow among all team members.
• Making status checks mandatory before each merge. Status checks make it easier to root out errors before they impact important branches. The Checks API offered by GitHub makes this feature capable of facilitating continuous integration with detailed commit feedback and more.
• Requiring commits be signed. Every commit in your codebase can be signed with a cryptographic key to ensure committers cannot impersonate one another. Once cryptographic keys have been created, the process of signing individual commits can be automated for simplicity as well. Be aware that this does not prevent merging unsigned commits; read our vulnerability report for more context.
• Allowing deletions. Managing deletions while using protected branches used to be a bit unintuitive on GitHub, but the feature has since been greatly refined, allowing for granular control of branch name pattern deletion rules.
• Making conversation resolution necessary for merges. With this option enabled, the conversations on code intended to form part of a merge will first need to be resolved before the operation can proceed.
• Requiring a linear history. A linear history on GitHub can help your team keep track of when commits were made by eliminating branch merges and forcing all contributors to rebase before merging instead. This leads to every commit working with GitHub's fast-forward mechanism and effectively removing all branches, making your project's history look like a straight line.
• Including administrators. This rule simply applies the other rules to administrators as well, ensuring no one is above the (code security) law you have laid out. However, certain rules are always applied to administrators too—allowing deletions and allowing forced pushes.
• Restricting matching branch push rights. This option makes it easier for teams to stave off "force-push" attacks, effectively limiting who can push to important branches.
• Allowing forced pushes. To further protect a branch in GitHub from push attacks, you can choose not to allow force pushes for all users with actual push access to a matching branch.

Mergify makes automating codebase security easy

Setting up branch protection rules on GitHub is essential to keeping all of your code safe from harm.

That being said, it can become too strict and not flexible enough for your use cases. For example, you might want to require a certain CI to pass before merging, but the CI list might depend on a label. Or you might want the number of approval for a pull request to be different depending on if the author is a senior or an intern.

While Mergify plays nicely with native branch protections, it can also supersede them. Your merging strategy can be defined upfront and left to run on its own, automatically merging pull requests that have completed all of the review and continuous integration steps you took time to establish.

Use our YAML-based configuration language to define your rules and automatically merge your pull request:

pull_request_rules:
  - name: automatic merge a PR when ready
    conditions:
      # Require 2 approvals, or only one if the label is `hotfix`
      - or:
        - "#approved-review-by>=2"
        - and:
          - "#approved-review-by>=1"
          - label=hotfix
      - check-success=circleci: test
    actions:
      merge:
        method: squash

The above example allows to merge automatically a pull request when it's approved — the number of approval depending on a label — and the CI passes. Simple as that. And the possibilities are infinite.

Set up and manage a branch protection rule with finer control over all of the details than you would have access to on GitHub alone, then let Mergify make sure your team adheres to it in real-time.

Sign up for a demo today to see just how much Mergify can help.