Most teams I have worked with use a shared repository for collaboration. Everyone gets write access, branch protection rules enforce reviews, and the platform handles the rest. This is the default on GitHub and GitLab. It works. But it is not how Git was designed to work.
Git already has a collaboration model. It is called forking. And it solves most of the problems that branch protection rules were invented to address.
1. How Git was meant to work
Git is a distributed version control system. Every clone is a complete copy of the repository. Collaboration happens through explicit integration: you work in your own copy and propose changes to a maintainer who decides what gets merged.
There is no need for fine-grained permissions inside a repository because trust boundaries are structural. If you do not have write access, you work in a fork. That is not a workaround. That is the design.
The Linux kernel works this way. Write access to the canonical repository is extremely limited. Contributors work in their own forks. Changes are reviewed and merged by a small group of maintainers. Trust is explicit. Integration is deliberate.
2. What platforms changed
GitHub normalized a different model. Teams work in a single shared repository. Access is controlled through roles: read, write, admin. Branch protection rules are layered on top to enforce reviews, require CI checks, and prevent direct pushes.
These mechanisms are often presented as essential. Sometimes they are framed as compensating for something Git lacks.
That framing is wrong. Git does not lack a permission model. It has one. It uses repository boundaries instead of branch permissions. Forking is the mechanism. By collapsing everything into a single repository, platforms created the need for branch protection rules—a more complex and more fragile version of what forks already provide.
3. What forks give you
Forks enforce separation between contributors and the canonical codebase. It does not matter if you are an external contributor or an internal employee. You cannot modify the main repository unless you have been explicitly granted that privilege. Trust is earned, not assumed.
Forks simplify access control. You either have write access or you do not. There is no hierarchy of roles to manage, no permission creep where people accumulate privileges over time without anyone noticing. In role-based systems, permissions tend to drift into inconsistent configurations. Forks avoid this entirely.
Forks make review mandatory by design. Contributors cannot push directly, so all changes go through a proposal and review process. Branch protection rules try to enforce the same thing, but they are policy-based. Someone with sufficient privileges can override them. Structural constraints are harder to bypass.
Forks also handle CI/CD secrets better. Workflows triggered from forks are typically restricted from accessing secrets because the fork is a less-trusted environment. This is a feature. It forces a clean separation between untrusted contributions and privileged operations. In a shared repository, managing that separation is harder and more error-prone.
4. The overhead argument
The common objection is that forks add overhead. More repositories to manage, more clutter.
I disagree. Forks are scoped to individual users. They do not affect the main repository. Maintainers see a clean, focused canonical repo. The perceived inconvenience is a reflection of tooling defaults, not a flaw in the model.
6. Closing thought
The question is not whether branch permissions are useful. It is whether they are necessary.
Git already answered that. The answer is forks.
