| title | Set Git Repository Permissions |
|---|---|
| titleSuffix | Azure Repos |
| description | Steps for how to grant or restrict access to a Git repository feature. |
| ms.service | azure-devops-repos |
| ms.topic | quickstart |
| monikerRange | <= azure-devops |
| ms.date | 04/14/2021 |
| ms.subservice | azure-devops-repos-git |
| ai-usage | ai-assisted |
[!INCLUDE version-lt-eq-azure-devops]
[!INCLUDE ai-assistance-callout]
Manage 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 Manage access by using permissions.
[!INCLUDE azure-repos-prerequisites]
::: moniker range="azure-devops"
To contribute to the source code, you need Basic access level or greater. Users who are granted Stakeholder access for private projects don't have access to source code. Users who are granted Stakeholder access for public projects have the same access as Contributors and users granted Basic access. For more information, see About access levels.
::: moniker-end
::: moniker range="< azure-devops"
To contribute to the source code, you need Basic access level or greater. Users who are granted Stakeholder access don't have access to source code. For more information, see About access levels. ::: moniker-end
By default, members of the project Contributors group have permissions to contribute to a repository. This permission level 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.
[!INCLUDE temp]
:::moniker range=">= azure-devops-2022"
Beginning with Azure DevOps sprint 224 (Azure DevOps Services and Azure DevOps Server 2022.1 and higher), Edit policies permission is no longer granted automatically to branch creators. Previously, when you created a new branch, you were granted permission to edit policies on that branch.
With this update, the default behavior changed. This permission isn't granted even if the Permission management setting is switched on for the repository. You must have the Edit policies permission granted explicitly (either manually or through REST API) by security permission inheritance or through a group membership.
:::moniker-end
::: moniker range="azure-devops"
You set Git repository permissions from Project Settings > Repositories.
-
Open the web portal and select the project where you want to add users or groups. To select another project, see Switch project, repository, team.
-
Select Project settings > Repositories.
-
To set the permissions for all Git repositories, select Security.
:::image type="content" source="media/git-permissions/open-repositories-s-185.png" alt-text="Screenshot that shows selecting Project settings > Repositories > Security.":::
-
To set permissions for a specific repository, select the repository and then select Security.
:::image type="content" source="media/git-permissions/choose-git-repo-security-callouts.png" alt-text="Screenshot that shows selecting the repository and then selecting Security.":::
::: moniker-end
::: moniker range="< azure-devops"
You can manage access to a repository by setting the permission state to Allow or Deny for a single user or a security group.
::: moniker-end
::: moniker range="<azure-devops"
-
Open the web portal and select the project where you want to add users or groups. To select another project, see Switch project, repository, team.
-
Select Project settings > Repositories.
-
To set the permissions for all Git repositories for a project, select Git Repositories and then select the security group whose permissions you want to manage. For example, select Contributors, and then select the permission for Create repository.
[!INCLUDE temp]
[!INCLUDE temp]
Otherwise, select a specific repository and select the security group whose permissions you want to manage.
[!NOTE] You might add a user or group and not change any permissions for that user or group. After the permissions page refreshes, the user or group no longer appears.
-
Select Save changes.
::: moniker-end
::: moniker range="azure-devops"
To set permissions for a custom security group, you must previously define that group. For more information, see Change project-level permissions.
-
To set permissions for a specific group, select the group. For example, select Contributors.
:::image type="content" source="media/git-permissions/choose-security-group.png" alt-text="Screenshot that shows selecting the Contributors group.":::
-
Change one or more permissions. To grant permissions, change Not Set to Allow. To restrict permissions, change Allow to Deny.
:::image type="content" source="media/git-permissions/change-permissions.png" alt-text="Screenshot that shows three permissions changed for the Contributors group.":::
The permission changes are automatically saved for the selected group.
-
To set permissions for a specific user, enter the name of the user in the search filter and select from the identities that appear.
[!div class="mx-imgBorder"]
-
Make the changes to the permission set.
[!INCLUDE temp]
The permission changes are automatically saved for the selected group.
You might add a user or group and not change any permissions for that user or group. After the permissions page refreshes, the user or group no longer appears.
To enable or disable inheritance for a specific repository, select the repository and then move the Inheritance slider to either the on or off position.
[!div class="mx-imgBorder"]
To learn about inheritance, see About permissions and groups.
::: moniker-end
There are many scenarios where you have the occasional need to bypass a branch policy. Some examples are when you revert a change that caused a build break or apply 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 they completed a pull request. However, that permission also granted users the ability to push directly to the branch and bypass the PR process entirely.
The Exempt from policy enforcement permission now offers 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 can use the override experience for pull requests.
- Bypass policies when pushing: Users with this permission can push directly to branches with required policies that are configured.
You can use the bypass option when necessary by granting the first permission and denying the second. You still have protection from accidentally pushing to a branch with policies.
Note
This change doesn't introduce any behavior changes. Users that were formerly granted Allow for Exempt from policy enforcement are granted Allow for both new permissions. They can both override completion on PRs and push directly to branches with policies.