What are protected branches?
Protected branches are branches in a Git repository that are configured to prevent changes from being merged into them without approval from a specific set of people. This can be useful for ensuring that changes to important branches are reviewed and approved before they are merged into the main branch.
Why use protected branches?
There are several reasons why you might want to use protected branches in your Git repository:
- To prevent accidental merges: If you have a branch that contains important changes, you don’t want someone accidentally merging in changes that could break the build or introduce other problems. Protected branches can help to prevent this by requiring someone to explicitly approve any changes before they are merged into the branch.
- To enforce code quality standards: You can use protected branches to enforce code quality standards by requiring that all changes to a branch be approved by a reviewer who has been trained on your standards. This can help to ensure that all changes are of high quality and that your code base is well-maintained.
- **To control the release process: **You can use protected branches to control the release process by requiring that all changes to a branch be approved by a release manager before they are merged into the release branch. This can help to ensure that all changes are tested and ready for release before they are made available to users.
- To achieve a compliance framework such as SOC 2 that requires tracking all of your changes. Protected branches are a great way to make sure that your security controls are enforced across all of your repositories for all of your developers. They’re a common requirements for SDLC policies
The most important rules for protected branches
GitHub and GitLab both have similar branch protection rules, the below are the most important for security
- Require pull requests and disable force push. Force push is an option that developers can use to override the commit history of a repository. This allows attackers to do a huge amount of damage or for costly mistakes in regards to compliance.
- Require approvers to merge pull requests to the main branch of a repository.
- Common best practices at least two other developers besides the author
- This also requires enforcing pull requests instead of allowing developers to push directly to repositories
- Double check your permissions for who has the authority to approve changes to a branch in GitHub this is commonly done through a codeowners file
- Require all checks to pass before code is merged into production
- Most teams have some kind of unit testing and security testing that occurs in pipeline enforcing these tests to pass validates that scanning is always happening within pipeline
- A more advanced option is enforcing signed commits. While more challenging to implement this is a necessary protection for larger businesses with more sensitive data
- Without signed commits developers have the ability to set whatever email address they would like for pushing changes. this allows them to impersonate other users which an attacker may use to use the trust of a higher level employee.
By following these rules, you can help to ensure that protected branches are effective in protecting your code base and preventing accidental or malicious changes.
