Repository permissions
Configure permissions in the source control repository
Where permissions apply
Azure Repos permissions can be set at organisation, project, repository and branch level, inheriting downward. Branch-level control is what allows main to be treated differently from every other branch in the same repository.
The precedence rule, again
Deny beats Allow, and Not set means inherit. A user in two groups, one allowing and one denying, is denied — and adding them to a further allowing group later will not change that.
This is the same model as project permissions, and the same trap: an explicit Deny is a decision that outlives the reason for it.
Permissions and policies do different jobs
| Control | Governs |
|---|---|
| Permissions | Who may perform an operation — push, force push, delete, manage |
| Branch policies | What must be true before a change can land |
Both are needed. Contribute permission on a branch with no policy is an unreviewed path to production; a policy without permission control leaves force push and branch deletion available to anyone who can push.
Notable permissions
Force push and Manage permissions deserve deliberate assignment. Force push rewrites history under everyone's clones; Manage permissions lets its holder grant themselves anything else.
Primary sources