Partage via


Consultez la section Autorisations de référentiel Git

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Vous pouvez gérer l’accès aux référentiels pour verrouiller qui peut contribuer à votre code source et gérer d’autres fonctionnalités. Vous pouvez définir des autorisations sur tous les référentiels Git en apportant des modifications à l’entrée Référentiels Git de niveau supérieur. Les référentiels individuels héritent des autorisations de l’entrée Référentiels Git de niveau supérieur.

Notes

Les branches héritent d’un sous-ensemble d’autorisations des affectations effectuées au niveau du référentiel. Pour obtenir des autorisations et des stratégies de branche, consultez Définir des autorisations de branche et Améliorer la qualité du code avec les stratégies de branche.

Pour savoir à qui attribuer des niveaux d'autorisation plus élevés, consultez la section Gérer l'accès à l'aide d’autorisations.

Prérequis

  • Vous devez avoir un projet. Si vous n’avez pas encore de projet, créez-en un dans Azure DevOps ou configurez-en un dans Azure DevOps local.
  • Vous devez être membre du groupe Administrateurs de projets ou définir vos Autorisations de gestion sur Autoriser pour les référentiels Git.

Pour contribuer au code source, vous devez disposer d’un niveau d’accès de base ou supérieur. Les utilisateurs qui bénéficient d’un accès en tant que partie prenante pour des projets privés n’ont pas accès au code source. Les utilisateurs qui bénéficient d’un accès en tant que partie prenante pour les projets publics ont droit aux mêmes accès que les contributeurs et que ceux qui bénéficient d’un accès de base. Pour plus d’informations, consultez À propos des niveaux d’accès.

Pour contribuer au code source, vous devez disposer d’un niveau d’accès de base ou supérieur. Les utilisateurs qui bénéficient d’un accès en tant que partie prenante n’ont pas accès au code source. Pour plus d’informations, consultez À propos des niveaux d’accès.

Autorisations de référentiel par défaut

Par défaut, les membres du groupe Contributeurs du projet sont autorisés à contribuer à un référentiel. Cela inclut la possibilité de créer des branches, de créer des balises et de gérer des notes. Pour obtenir une description de chaque groupe de sécurité et niveau d’autorisation, consultez Autorisations et référence de groupe.

Permission

Lecteurs

Contributeurs

Administrateurs de build

Administrateurs de projets


Lire (cloner, extraire et explorer le contenu d’un référentiel) ; peut également créer, commenter, voter et contribuer aux demandes de tirage

✔️

✔️

✔️

✔️

Contribuer, Créer des branches, Créer des étiquettes et Gérer des notes

✔️

✔️

✔️

Créer un référentiel, Supprimer un référentielet Renommer un référentiel

✔️

Modifier les stratégies, Gérer les autorisations, Supprimer les verrous d’autres utilisateurs

✔️

Contourner les stratégies lors de la fin des demandes de tirage, Contourner les stratégies lors de l’envoi, Forcer l’envoi (réécrire l’historique, supprimer des branches et des balises)
(non défini pour un groupe de sécurité)


À compter d’Azure DevOps sprint 224 (Azure DevOps Services et Azure DevOps Server 2022.1 et ultérieur), l’autorisation Modifier les stratégies n’est plus accordée automatiquement aux créateurs de branche. Auparavant, lorsque vous créiez une branche, vous aviez l’autorisation de modifier les stratégies sur cette branche. Avec cette mise à jour, nous changeons le comportement par défaut, qui est maintenant de ne pas accorder cette autorisation même si le paramètre Gestion des autorisations est activé pour le dépôt. Vous aurez besoin de l’autorisation Modifier les stratégies accordée explicitement (manuellement ou via l’API REST) par héritage des autorisations de sécurité ou par appartenance à un groupe.

Ouvrir la sécurité pour un référentiel

Vous définissez les autorisations de référentiel Git à partir de Référentiels>de paramètres de projet.

  1. Ouvrez le portail web et choisissez le projet dans lequel vous souhaitez ajouter des utilisateurs ou des groupes. Pour choisir un autre projet, consultez Changer de projet, référentiel, équipe.

  2. Ouvrez Référentiels>de paramètres de projet.

    Pour définir les autorisations pour tous les référentiels Git, choisissez Sécurité.

    Par exemple, ici, nous choisissons (1) Paramètres du projet, (2) Référentiels, puis (3) Sécurité.

    Capture d’écran montrant le choix de la sécurité des >référentiels> des paramètres de projet.

  3. Sinon, pour définir les autorisations pour un référentiel spécifique, choisissez (1) le référentiel, puis sélectionnez (2) Sécurité.

    Capture d’écran montrant le choix des paramètres de projet >Choisir une sécurité de référentiel>.

Définir des autorisations pour un référentiel

Vous pouvez gérer l’accès à un référentiel en définissant l’état d’autorisation sur Autoriser ou Refuser pour un seul utilisateur ou un groupe de sécurité.

  1. Ouvrez le portail web et choisissez le projet dans lequel vous souhaitez ajouter des utilisateurs ou des groupes. Pour choisir un autre projet, consultez Changer de projet, référentiel, équipe.

  2. Pour définir les autorisations pour tous les référentiels Git d’un projet, choisissez Référentiels Git, puis choisissez le groupe de sécurité dont vous souhaitez gérer les autorisations.

    Par exemple, ici, nous choisissons (1) Paramètres du projet, (2) Référentiels, (3) Référentiels Git, (4) le groupe Contributeurs, puis (5) l’autorisation pour Créer un référentiel.

    Pour afficher l’image complète, cliquez sur l’image à développer. Choisissez l’icône Fermer pour fermer.

    Sécurité des>référentiels Git>des référentiels>de code>des paramètres de projet

    Notes

    Vous ne pourrez peut-être pas trouver un utilisateur à partir d’une page d’autorisations ou d’un champ d’identité si l’utilisateur n’a pas été ajouté au projet, soit en l’ajoutant à un groupe de sécurité, soit à une équipe de projet. En outre, lorsqu’un utilisateur est ajouté à Microsoft Entra ID ou Active Directory, il peut y avoir un délai entre le moment où il est ajouté au projet et le moment où il peut faire l’objet d’une recherche à partir d’un champ d’identité. Le délai peut être compris entre 5 minutes et 7 jours.

    Sinon, choisissez un référentiel spécifique et choisissez le groupe de sécurité dont vous souhaitez gérer les autorisations.

    Notes

    Si vous ajoutez un utilisateur ou un groupe et que vous ne modifiez aucune autorisation pour cet utilisateur ou ce groupe, l’utilisateur ou le groupe que vous avez ajouté n’apparaît plus lors de l’actualisation de la page des autorisations.

  3. Lorsque vous avez terminé, choisissez Enregistrer les modifications.

Modifiez les autorisations d’un groupe de sécurité

Pour définir des autorisations pour un groupe de sécurité personnalisé, vous devez avoir défini ce groupe précédemment. Consultez Définir des autorisations au niveau du projet.

  1. Pour définir les autorisations pour un groupe spécifique, choisissez le groupe. Par exemple, ici, nous choisissons le groupe Contributeurs.

    Capture d’écran montrant le choix du groupe Contributeurs.

  2. Modifiez une ou plusieurs autorisations. Pour accorder des autorisations, remplacez Non défini par Autoriser. Pour restreindre les autorisations, remplacez Autoriser par Refuser.

    Capture d’écran montrant trois autorisations modifiées pour le groupe Contributeurs.

  3. Lorsque vous avez terminé, quittez la page. Les modifications d’autorisation sont automatiquement enregistrées pour le groupe sélectionné.

Définir des autorisations pour un utilisateur spécifique

  1. Pour définir des autorisations pour un utilisateur spécifique, entrez le nom de l’utilisateur dans le filtre de recherche et sélectionnez parmi les identités qui s’affichent.

    Ajouter un utilisateur ou un groupe

    Ensuite, apportez les modifications au jeu d’autorisations.

    Notes

    Vous ne pourrez peut-être pas trouver un utilisateur à partir d’une page d’autorisations ou d’un champ d’identité si l’utilisateur n’a pas été ajouté au projet, soit en l’ajoutant à un groupe de sécurité, soit à une équipe de projet. En outre, lorsqu’un utilisateur est ajouté à Microsoft Entra ID ou Active Directory, il peut y avoir un délai entre le moment où il est ajouté au projet et le moment où il peut faire l’objet d’une recherche à partir d’un champ d’identité. Le délai peut être compris entre 5 minutes et 7 jours.

  2. Lorsque vous avez terminé, quittez la page. Les modifications d’autorisation sont automatiquement enregistrées pour le groupe sélectionné.

Notes

Si vous ajoutez un utilisateur ou un groupe et que vous ne modifiez aucune autorisation pour cet utilisateur ou ce groupe, l’utilisateur ou le groupe que vous avez ajouté n’apparaît plus lors de l’actualisation de la page des autorisations.

Activez ou désactivez l’héritage pour un référentiel spécifique

Exempt de l’application de la stratégie et de contournement des autorisations de stratégie

Il existe de nombreux scénarios où vous avez parfois besoin de contourner une stratégie de branche. Par exemple, lors de la restauration d’une modification qui a provoqué un arrêt de build ou l’application d’un correctif logiciel au milieu de la nuit. Auparavant, l’autorisation Exempt de l’application des stratégies aidait les équipes à gérer les utilisateurs qui avaient la possibilité de contourner les stratégies de branche lors de la fin d’une demande de tirage. Toutefois, cette autorisation a également accordé la possibilité d’envoyer directement à la branche, en contournant entièrement le processus de demande de tirage.

Pour améliorer cette expérience, nous fractionnons l’autorisation Exempt de l’application des stratégies pour offrir davantage de contrôle aux équipes qui accordent des autorisations de contournement. Les deux autorisations suivantes remplacent l’ancienne autorisation :

  • Contourner les stratégies lors des demandes de tirage. Les utilisateurs disposant de cette autorisation pourront utiliser l’expérience « Remplacer » pour les demandes de tirage.
  • Contourner les stratégies lors de l’envoi. Les utilisateurs disposant de cette autorisation pourront envoyer directement aux branches dont les stratégies requises sont configurées.

En accordant la première autorisation et en refusant la seconde, un utilisateur peut utiliser l’option de contournement si nécessaire, mais aura toujours la protection contre l’envoi accidentel vers une branche avec des stratégies.

Notes

Cette modification n’introduit aucune modification de comportement. Les utilisateurs qui bénéficiaient auparavant d’une autorisationExempt de l’application des stratégies ont accès aux deux nouvelles autorisations. Ils pourront donc remplacer la saisie semi-automatique sur les demandes de tirage et envoyer directement aux branches avec des stratégies.