Set Git repository permissions

Azure Repos | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2013

You grant or restrict access to repositories to lock down who can contribute to your source code and manage other features. You can set permissions across all Git repositories by making changes to the top-level Git repositories entry. Individual repositories inherit permissions from the top-level Git Repositories entry.

Note

Branches inherit a subset of permissions from assignments made at the repository level. For branch permissions and policies, see Set branch permissions and Improve code quality with branch policies.

For guidance on who to provide greater permission levels, see Grant or restrict access using permissions.

Prerequisites

To contribute to the source code, you must be granted Basic access level or greater. Users granted Stakeholder access for private projects have no access to source code. Users granted Stakeholder access for public projects have the same access as Contributors and those granted Basic access. To learn more, see About access levels.

To contribute to the source code, you must be granted Basic access level or greater. Users granted Stakeholder access have no access to source code. To learn more, see About access levels.

Default repository permissions

By default, members of the project Contributors group have permissions to contribute to a repository. This includes the ability to create branches, create tags, and manage notes. For a description of each security group and permission level, see Permissions and group reference.

Permission

Readers

Contributors

Build Admins

Project Admins

Read (clone, fetch, and explore the contents of a repository); also, can create, comment on, vote, and Contribute to pull requests

✔️

✔️

✔️

✔️

Contribute to a repository, Create branches, Create tags, and Manage notes

✔️

✔️

✔️

Bypass policies when pushing to a repository

✔️

Create repository, Delete repository, and Rename repository

✔️

Edit policies, Force push (rewrite history, delete branches and tags), Manage permissions, Remove others' locks

✔️

Bypass policies when completing pull requests (not set for any security group)

By default, the project-level Readers groups have read-only permissions.

Permission

Contributors

Build Admins

Project Admins

Branch Creation: At the repository level, can push their changes to branches in the repository. Does not override restrictions in place from branch policies. At the branch level, can push their changes to the branch and lock the branch.

✔️

✔️

✔️

Contribute: At the repository level, can push their changes to branches in the repository. Does not override restrictions in place from branch policies. At the branch level, can push their changes to the branch and lock the branch.

✔️

✔️

✔️

Note Management: Can push and edit Git notes to the repository. They can also remove notes from items if they have the Force permission.

✔️

✔️

✔️

Tag Creation: Can push tags to the repository, and can also edit or remove tags if they have the Force permission.

✔️

✔️

✔️

Administer: Delete and rename repositories: If assigned to the top-level Git repositories entry, can add additional repositories. At the branch level, users can set permissions for the branch and unlock the branch. The Administer permission set on an individual Git repository does not grant the ability to rename or delete the repository. These tasks require Administer permissions at the Git repositories top-level.

✔️

Rewrite and destroy history (force push): Can force an update to a branch and delete a branch. A force update can overwrite commits added from any user. Users with this permission can modify the commit history of a branch.

✔️

Open Security for a repository

You set Git repository permissions from Project Settings>Repositories.

  1. Open the web portal and choose the project where you want to add users or groups. To choose another project, see Switch project, repository, team.

  2. Open Project settings>Repositories.

    To set the permissions for all Git repositories, choose Security.

    For example, here we choose (1) Project settings, (2) Repositories, and then (3) Security.

    Screenshot showing choosing Project settings>Repositories>Security.

  3. Otherwise, to set permissions for a specific repository, choose (1) the repository and then choose (2) Security.

    Screenshot showing choosing Project settings>Choose a repository>Security.

Set permissions for a repository

You can grant or restrict access to a repository by setting the permission state to Allow or Deny for a single user or a security group.

  1. Open the web portal and choose the project where you want to add users or groups. To choose another project, see Switch project, repository, team.

  2. To set the permissions for all Git repositories for a project, choose Git Repositories and then choose the security group whose permissions you want to manage.

    For example, here we choose (1) Project Settings, (2) Repositories, (3) Git repositories, (4) the Contributors group, and then (5) the permission for Create repository.

    To see the full image, click the image to expand. Choose the close icon close icon to close.

    Project Settings>Code>Repositories>Git repositories>Security

    Note

    You may not be able to find a user from a permissions page or identity field if the user hasn't been added to the project—either by adding it to a security group or to a project team. Also, when a user is added to Azure Active Directory or Active Directory, there can be a delay between the time they are added to the project and when they are searchable from an identity field. The delay can be between 5 minutes to 7 days.

    Otherwise, choose a specific repository and choose the security group whose permissions you want to manage.

    Note

    If you add a user or group, and don't change any permissions for that user or group, then upon refresh of the permissions page, the user or group you added no longer appears.

  3. When done, choose Save changes.

  1. Open the web portal and choose the project where you want to add users or groups. To choose another project, see Switch project, repository, team.

  2. Choose the gear icon to open the administrative context.

    Open Project Settings, horizontal nav

  3. Choose Version Control.

  4. To set the set the permissions for all Git repositories for a project, (1) choose Git Repositories and then (2) choose the security group whose permissions you want to manage.

    Note

    You may not be able to find a user from a permissions page or identity field if the user hasn't been added to the project—either by adding it to a security group or to a project team. Also, when a user is added to Azure Active Directory or Active Directory, there can be a delay between the time they are added to the project and when they are searchable from an identity field. The delay can be between 5 minutes to 7 days.

    Otherwise, choose a specific repository and choose the security group whose permissions you want to manage.

  5. Choose the setting for the permission you want to change.

    Here we grant permissions to the Contributors group to (3) Create repository.

    Security dialog for all Git repositories, Contributors group

  6. When done, choose Save changes.

Individual repositories inherit permissions from the top-level Git Repository security settings. Branches inherit permissions from assignments made at the repository level.

  1. Open the web portal and choose the project where you want to add users or groups. To choose another project, see Switch project, repository, team.

  2. Choose the gear icon to open the administrative context.

  3. Choose Version Control.

  4. To set the set the permissions for all Git repositories for a project, (1) choose Git Repositories and then (2) choose the security group whose permissions you want to manage.

    Otherwise, choose a specific repository and choose the security group whose permissions you want to manage.

  5. Choose the setting for the permission you want to change.

    Git repository permissions dialog, prior to TFS 2017.1

  6. When done, choose Save changes.

Change permissions for a security group

To set permissions for a custom security group, you must have defined that group previously. See Set permissions at the project- or collection-level.

  1. To set permissions for a specific group, choose the group. For example, here we choose the Contributors group.

    Screenshot showing choosing Contributors group.

  2. Change one or more permissions. To grant a permissions, change Not Set to Allow. To restrict permissions, change Allow to Deny.

    Screenshot showing three permissions changed for the Contributors group.

  3. When done, navigate away from the page. The permission changes are automatically saved for the selected group.

Set permissions for a specific user

  1. To set permissions for a specific user, enter the name of the user into the search filter and select from the identities that appear.

    Add user or group

    Then make the changes to the permission set.

    Note

    You may not be able to find a user from a permissions page or identity field if the user hasn't been added to the project—either by adding it to a security group or to a project team. Also, when a user is added to Azure Active Directory or Active Directory, there can be a delay between the time they are added to the project and when they are searchable from an identity field. The delay can be between 5 minutes to 7 days.

  2. When done, navigate away from the page. The permission changes are automatically saved for the selected group.

Note

If you add a user or group, and don't change any permissions for that user or group, then upon refresh of the permissions page, the user or group you added no longer appears.

Enable or disable inheritance for a specific repository

Exempt from policy enforcement and bypass policy permissions

There are many scenarios where you have the occasional need to bypass a branch policy. For example, when reverting a change that caused a build break or applying a hotfix in the middle of the night. Previously, the Exempt from policy enforcement permission helped teams manage which users were granted the ability to bypass branch policies when completing a pull request. However, that permission also granted the ability to push directly to the branch, bypassing the PR process entirely.

To improve this experience, we split the Exempt from policy enforcement permission to offer more control to teams that are granting bypass permissions. The following two permissions replace the former permission:

  • Bypass policies when completing pull requests. Users with this permission will be able to use the "Override" experience for pull requests.
  • Bypass policies when pushing. Users with this permission will be able to push directly to branches that have required policies configured.

By granting the first permission and denying the second, a user can use the bypass option when necessary, but will still have the protection from accidentally pushing to a branch with policies.

Note

This change does not introduce any behavior changes. Users that were formerly granted Allow for Exempt from policy enforcement are granted Allow for both new permissions, so they'll be able to both override completion on PRs and push directly to branches with policies.