Branch Protection

Software is rarely written by a single person. Teams work together on the same collection of program text, and a tool called Git manages every single change in the process. Within this tool there are lines of development, so-called branches: parallel working versions of the same program. One of these lines is the official one, from which the product for customers is ultimately built. Branch Protection is a set of rules that safeguards exactly this official line. It defines who is allowed to make changes there and which checks must be passed beforehand.

Why the main line is protected in particular

In most projects, the official development line is called main or master. Whatever is placed there generally goes into production automatically: into the app, onto the website, into the product. An error at this point is therefore not an internal problem but immediately visible to all users. At a bank or a payment service provider, a broken version can cost millions.

Without protection rules, a single careless command is enough. A developer can overwrite colleagues' work or delete the history of changes. Such accidents are rare but costly, because they are hard to undo.

There is also a security aspect. If attackers steal a developer’s password, they could, without protection rules, insert malicious code directly into the product. This is exactly how software supply chain attacks arise. Branch Protection makes such solo actions impossible, because a second person must always give approval.

Which rules are typically set

The core of any Branch Protection is a prohibition: no one writes directly into the protected line. Anyone who wants to change something first creates their own side branch and works there. They then submit a formal request, the pull request. This is the request to have one’s own work merged into the official version.

Further conditions are attached to this request. It is common for at least one colleague to have read and approved the code. Projects frequently also require automated tests to pass. Such tests are small programs that check whether the software still does the right thing. Only once all the checkmarks are green does the system allow the merge.

A comparison makes this vivid. The protected line is like the clean room of a chip factory: you don’t enter it in street clothes, but only through an airlock with fixed controls. It is important to distinguish this from access management. Who is allowed to work on the project at all is governed by permissions. Branch Protection governs what even authorized people are not allowed to do without oversight.

Branch Protection on GitHub and GitLab

In practice, one encounters the term on platforms such as GitHub, GitLab, or Bitbucket. There, Branch Protection is a menu item in the project settings, not additional software. You tick checkboxes and enter numbers, such as the minimum number of required approvals. GitHub now also calls this Rulesets, GitLab refers to Protected Branches.

In the discussion about AI tools, the topic has newly gained importance. Coding assistants and autonomous software agents today generate large amounts of code and can submit pull requests themselves. The protection rules are then the point at which a human still takes another look. Before a machine’s suggestions reach a banking product, someone must approve them.

In news reports, Branch Protection rules also come up in connection with security incidents and audits. Regulated companies must demonstrate to regulators that changes to their software proceed in a controlled manner. A log from protected branches is a common piece of evidence for this. A typical misconception, incidentally, is to view Branch Protection as a brake. Good teams configure the rules so that routine changes pass through in minutes and only risky ones take longer.