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 built into its most basic operation: the clone. Every clone is a complete, independent repository. Collaboration happens by proposing changes from your clone to a maintainer who decides what gets merged. Platforms like GitHub, GitLab, and Bitbucket call this a "fork"—but underneath, it is just a hosted clone with a pull request workflow on top.
This distinction matters. The trust model is not a platform feature. It is a Git feature.
1. How Git was meant to work
Git is a distributed version control system. Every clone is a complete copy of the repository. You work in your own clone, publish it somewhere others can reach, and propose changes to a maintainer who decides what gets integrated.
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 your own clone. 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 publish their own clones. Changes are reviewed and merged by a small group of maintainers. Trust is explicit. Integration is deliberate.
When platforms host this clone for you and attach a pull request workflow, they call it a "fork." The mechanism is the same.
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. Cloning 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 separate clones 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 structural separation—your own clone, your own repository, integrated only through deliberate review.
