Partager via

Stratégies et paramètres de branche

  • Article

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

Les stratégies de branche aident les équipes à protéger leurs branches importantes de développement. Les stratégies appliquent les standards de qualité du code et de gestion des modifications de votre équipe. Cet article explique comment définir et gérer des stratégies de branche. Pour obtenir une vue d’ensemble de toutes les stratégies et paramètres de référentiel et de branche, consultez Paramètres et stratégies de référentiel Git.

Une branche dans laquelle les stratégies requises sont configurées ne peut pas être supprimée et nécessite des requêtes pull (PR) pour toutes les modifications.

Prérequis

  • Pour définir des stratégies de branche, vous devez être membre du groupe de sécurité Administrateurs de projet ou disposer d’autorisations De modification au niveau du référentiel. Pour plus d’informations, consultez Définir des autorisations pour un référentiel.

Configurer des stratégies de branche

Pour gérer les stratégies de branche, sélectionnez Branches de Repos> pour ouvrir la page Branches dans le portail web.

Capture d’écran montrant l’élément de menu Branches.

Vous pouvez également accéder aux paramètres de stratégie de branche avec le nom de la branche >stratégies de branche >des stratégies >de référentiel ><des paramètres de projet>.

Les branches qui ont des stratégies affichent une icône de stratégie. Vous pouvez sélectionner l’icône pour accéder directement aux paramètres de stratégie de la branche.

Pour définir des stratégies de branche, recherchez la branche que vous souhaitez gérer. Vous pouvez parcourir la liste ou rechercher votre branche dans la zone nom de la branche de recherche en haut à droite.

Sélectionnez l’icône Autres options en regard de la branche, puis sélectionnez Stratégies de branche dans le menu contextuel.

Capture d’écran montrant Ouvrir les stratégies de branche à partir du menu contextuel.

Localisez dans la page votre branche. Vous pouvez parcourir la liste ou rechercher votre branche à l’aide de la zone Rechercher toutes les branches en haut à droite.

Capture d’écran montrant la page Branches.

Sélectionnez le bouton .... Sélectionnez Stratégies de branche dans le menu contextuel.

Capture d’écran montrant Ouvrir les stratégies de branche à partir du menu contextuel.

Configurez des stratégies sur la page des paramètres de la branche. Consultez les sections suivantes pour obtenir des descriptions et des instructions pour chaque type de stratégie.

Configurez vos stratégies dans la page Stratégies. Consultez les sections suivantes pour obtenir des descriptions de chaque type de stratégie. Sélectionnez Enregistrer les modifications pour appliquer votre nouvelle configuration de stratégie.

Capture d’écran montrant l’onglet Stratégies.

Demander un nombre minimal de réviseurs

Les révisions de code sont importantes pour les projets de développement de logiciels. Pour vous assurer que les équipes examinent et approuvent les demandes de tirage, vous pouvez exiger l’approbation d’un nombre minimal de réviseurs. La stratégie de base exige qu’un nombre spécifié de réviseurs approuvent le code, sans rejet.

Pour définir la stratégie, sous Stratégiesde branche, définissez Exiger un nombre minimal de réviseurssur Activé. Entrez le nombre requis de réviseurs, puis sélectionnez l’une des options suivantes :

Capture d’écran montrant la stratégie Activer la stratégie Exiger les révisions de code.

  • Sélectionnez Autoriser les demandeurs à approuver leurs propres modifications pour permettre au créateur d’une demande de tirage de voter sur son approbation. Sinon, le créateur peut toujours voter pour l'approbation du PR, mais son vote n'est pas pris en compte dans le calcul du nombre minimum de réviseurs.

  • Sélectionnez Empêcher le dernier pusher d’approuver ses propres modifications pour appliquer la séparation des tâches. Par défaut, toute personne disposant d’une autorisation push sur la branche source peut ajouter des commits et voter sur l’approbation de demande de tirage. La sélection de cette option signifie que le vote du pusher le plus récent ne compte pas, même s’il peut généralement approuver ses propres modifications.

  • Sélectionnez Autoriser l’achèvement même si certains réviseurs votent pour attendre ou rejeter pour autoriser l’achèvement de la demande de tirage, même si certains réviseurs votent contre l’approbation. Le nombre minimal de réviseurs doit toujours être approuvé.

  • Sous Quand de nouvelles modifications sont envoyées :
    • Sélectionnez Exiger au moins une approbation sur la dernière itération pour exiger au moins un vote d’approbation pour la dernière modification de la branche source.
    • Sélectionnez Réinitialiser tous les votes d'approbation (ne réinitialise pas les votes pour rejeter ou attendre) pour supprimer tous les votes d'approbation, mais conserver les votes pour rejeter ou attendre, chaque fois que la branche source change,
    • Sélectionnez Réinitialiser tous les votes du réviseur de code pour supprimer tous les votes du réviseur chaque fois que la branche source change, y compris les votes pour approuver, rejeter ou attendre.
  • Sous Quand de nouvelles modifications sont envoyées :
    • Sélectionnez Exiger au moins une approbation sur la dernière itération pour exiger au moins un vote d'approbation pour la dernière modification de la branche source. L'approbation de l'utilisateur n'est pas prise en compte pour les itérations précédentes non approuvées qu'il a poussées. Par conséquent, un autre utilisateur doit approuver la dernière itération. Exiger au moins une approbation à chaque itération est disponible dans Azure DevOps Server 2022.1 et versions ultérieures.
    • Sélectionnez Exiger au moins une approbation sur la dernière itération pour exiger au moins un vote d’approbation pour la dernière modification de la branche source.
    • Sélectionnez Réinitialiser tous les votes d'approbation (ne réinitialise pas les votes pour rejeter ou attendre) pour supprimer tous les votes d'approbation, mais conserver les votes pour rejeter ou attendre, chaque fois que la branche source change,
    • Sélectionnez Réinitialiser tous les votes du réviseur de code pour supprimer tous les votes du réviseur chaque fois que la branche source change, y compris les votes pour approuver, rejeter ou attendre.

Vérifiez la case Exiger des révisions de code

  • Si l'option Les requérants peuvent approuver leurs propres modifications n'est pas sélectionnée, le créateur de la demande de retrait peut toujours voter pour approuver sa demande de retrait, mais son vote n'est pas pris en compte dans le calcul du nombre minimum de réviseurs.
  • Si un réviseur rejette les modifications, la demande de tirage ne peut pas se terminer, sauf si vous sélectionnez Autoriser l’achèvement même si certains réviseurs votent pour attendre ou rejeter.
  • Vous pouvez réinitialiser les votes du réviseur de code lorsque de nouvelles modifications sont envoyées à la branche source. Sélectionnez Réinitialiser les votes du réviseur de code lorsqu’il existe de nouvelles modifications.

Si toutes les autres stratégies passent, le créateur peut terminer la demande de tirage lorsque le nombre requis de réviseurs l’approuve.

Rechercher les éléments de travail liés

Pour le suivi de la gestion des éléments de travail, vous pouvez exiger des associations entre les demandes de tirage et les éléments de travail. La liaison d’éléments de travail fournit un contexte supplémentaire pour vos modifications et garantit que les mises à jour passent par votre processus de suivi des éléments de travail.

Pour définir la stratégie, sous Stratégiesde branche, définissez Activé pour rechercher les éléments de travail liés. Ce paramètre nécessite que les éléments de travail soient liés à une demande de tirage pour que la demande de tirage soit fusionnée. Définissez le paramètre Facultatif pour avertir s’il n’existe aucun élément de travail lié, mais autorisez l’achèvement de la demande de tirage.

Capture d’écran de la nécessité d’éléments de travail liés dans les demandes de tirage.

Exigez des éléments de travail liés dans vos demandes de tirage

Vérifier la résolution des commentaires

La stratégie de résolution de commentaires vérifie si tous les commentaires de demande de tirage sont résolus.

Configurez une stratégie de résolution de commentaires pour votre branche en définissant Vérifier la résolutionde commentaires sur Activé. Ensuite, indiquez si la stratégie doit être obligatoire ou facultative.

Capture d'écran de Vérifier la résolution des commentaires.

Pour plus d’informations sur l’utilisation des commentaires de demande de tirage, consultez Vérifier les demandesde tirage.

Configurez une stratégie de résolution de commentaires pour votre branche en sélectionnant Vérifier la résolutionde commentaires.

Vérifier la résolution des commentaires

Pour plus d’informations sur l’utilisation des commentaires de demande de tirage, consultez Vérifier les demandesde tirage.

Limiter les types de fusion

Azure Repos a plusieurs stratégies de fusion et, par défaut, toutes sont autorisées. Vous pouvez conserver un historique de branche cohérent en appliquant une stratégie de fusion pour l’achèvement des demandes de tirage.

Définissez Limiter les types de fusion sur Activé pour limiter les types de fusion à autoriser dans votre référentiel.

Capture d'écran de Limiter les types de fusion.

  • La fusion de base (sans transfert rapide) crée un commit de fusion dans la cible dont les parents sont la cible et les branches sources.
  • La fusion Squash crée un historique linéaire avec un commit unique dans la branche cible avec les modifications de la branche source. En savoir plus sur la fusion Squash et la façon dont elle affecte l’historique des branches.
  • Le rebasage et l’avance rapide créent un historique linéaire en relisant les commits sources sur la branche cible sans commit de fusion.
  • Rebaser avec le commit de fusion relit les commits sources sur la cible et crée également un commit de fusion.

Notes

Cette fonctionnalité est disponible pour Azure DevOps Server 2020 et versions ultérieures.

Appliquer une stratégie de fusion

Conservez un historique de branche cohérent en appliquant une stratégie de fusion à la fin d’une demande de tirage. Sélectionnez Appliquer une stratégie de fusion et choisissez une option pour exiger que les demandes de tirage soient fusionnées à l’aide de cette stratégie.

Définir les exigences de fusion

  • Pas de fusion rapide : cette option fusionne l’historique de commit de la branche source lorsque la demande de tirage se ferme et crée un commit de fusion dans la branche cible.
  • Fusion squash : effectuez toutes les demandes de tirage avec une fusion Squash, en créant un commit unique dans la branche cible avec les modifications de la branche source. En savoir plus sur la fusion Squash et la façon dont elle affecte votre historique des branches.

Validation de build

Vous pouvez définir une stratégie nécessitant des modifications de la demande de tirage pour générer correctement avant que la demande de tirage ne puisse se terminer. Les stratégies de build réduisent les interruptions et conservent les résultats de vos tests. Les stratégies de génération aident même si vous utilisez l’intégration continue (CI) sur vos branches de développement pour détecter les problèmes au début.

Une stratégie de validation de build met en file d’attente une nouvelle build lorsqu’une nouvelle demande de tirage est créée ou que des modifications sont envoyées à une demande de tirage existante qui cible la branche. La stratégie de génération évalue les résultats de build pour déterminer si la demande de tirage peut être terminée.

Important

Avant de spécifier une stratégie de validation de build, vous devez disposer d’un pipeline de build. Si vous n’avez pas de pipeline, consultez Créer un pipelinede build. Choisissez le type de build qui correspond à votre type de projet.

Pour ajouter une stratégie de validation de build

  1. Sélectionnez le + bouton en regard de la validation de build.

    Capture d’écran montrant le bouton Ajouter en regard de la validation de build.

  2. Remplissez le formulaire Définir la stratégie de génération :

    Capture d'écran des paramètres de la stratégie de construction.

    • Sélectionnez le pipeline debuild.

    • Définissez éventuellement un filtre Chemin d’accès. En savoir plus sur les filtres Chemin d’accès dans les stratégies de branche.

    • Sous Déclencheur, sélectionnez Automatique (chaque fois que la branche source est mise à jour) ou Manuel.

    • Sous Condition requise pour la stratégie, sélectionnez Obligatoire ou Facultatif. Si vous choisissez Obligatoire, les builds doivent se terminer correctement pour terminer les demandes de tirage. Choisissez Facultatif pour fournir une notification de l’échec de build, mais autorisez toujours la fin des demandes de tirage.

    • Définissez une expiration de build pour vous assurer que les mises à jour de votre branche protégée n’interrompent pas les modifications pour les demandes de tirage ouvertes.

      • Immédiatement lorsque <le nom> de la branche est mis à jour : cette option définit l’état de la stratégie de génération de demande de tirage surl’échec chaque fois que la branche est mise à jour et remet en file d’attente une build. Ce paramètre garantit que les modifications de demande de tirage sont correctement générées même si la branche protégée change.

        Cette option est optimale pour les équipes dont les branches importantes ont peu de modifications. Les équipes travaillant dans des branches de développement très fréquentées peuvent trouver perturbant d'attendre une compilation à chaque mise à jour de la branche.

      • Après <n> heures si <le nom> de la branche a été mis à jour : cette option expire la stratégie actuelle d’état lorsque la branche protégée se met à jour si la build qui passe est antérieure au seuil que vous entrez. Cette option est un compromis entre toujours ou ne nécessitant jamais de build lorsque la branche protégée est mise à jour. Ce choix réduit le nombre de builds lorsque votre branche protégée a des mises à jour fréquentes.

      • Jamais : les mises à jour de la branche protégée ne modifient pas l’état de la stratégie. Cette valeur réduit le nombre de builds, mais peut causer des problèmes lors de l'achèvement de PRs qui n'ont pas été mis à jour récemment.

    • Entrez un nom d’affichage facultatif pour cette stratégie de build. Ce nom identifie la stratégie dans la page Stratégies de branche. Si vous ne spécifiez pas de nom d’affichage, la stratégie utilise le nom du pipeline de build.

  3. Sélectionnez Enregistrer.

Lorsque le propriétaire de la demande de tirage envoie des modifications qui sont correctement générés, la stratégie statut est mise à jour.

Si vous disposez d’une stratégie de build Immédiatement quand le <nom> de la branche est mis à jour ou Après <n> heures si <le nom> de la branche a été mis à jour, la stratégie d’état est mise à jour lorsque le branche protégée se met à jour, si la build précédente n’est plus valide.

Notes

Cette fonctionnalité est disponible pour Azure DevOps Server 2020 et versions ultérieures.

Définissez une stratégie nécessitant des modifications dans une demande de tirage pour générer correctement avec la branche protégée avant la fin de la demande de tirage. Les stratégies de build réduisent les interruptions et conservent les résultats de vos tests. Les stratégies de génération aident même si vous utilisez l’intégration continue (CI) sur vos branches de développement pour détecter les problèmes au début.

Si une stratégie de validation des builds est activée, un nouveau build est mis en file d'attente lorsqu'une nouvelle pull request est créée ou lorsque des modifications sont pushées dans une pull request existante qui cible la branche. La stratégie de build évalue ensuite les résultats de la build pour déterminer si la demande de tirage peut être terminée.

Important

Avant de spécifier une stratégie de validation de build, vous devez avoir une définition de build. Si vous n’en avez pas, consultez Créer une définition de build et choisissez le type de build qui correspond à votre type de projet.

Ajouter une stratégie de build

Choisissez Ajouter une stratégie de build et configurez vos options dans Ajouter une stratégiede build.

Paramètres de stratégie de build

  1. Sélectionnez la Définition de build.

  2. Choisissez le type de déclencheur. Sélectionnez Automatique (chaque fois que la branche source est mise à jour) ou Manuel.

  3. Sélectionnez l’exigence de stratégie. Si vous choisissez Obligatoire, les builds doivent se terminer correctement pour effectuer des demandes de tirage. Choisissez Facultatif pour fournir une notification de l’échec de build, mais autorisez toujours la fin des demandes de tirage.

  4. Définissez une expiration de build pour vous assurer que les mises à jour de votre branche protégée ne interrompent pas les modifications pour les demandes de tirage ouvertes.

    • Immédiatement lorsqu’elle branch name est mise à jour : cette option définit l’état de la stratégie de build dans une demande de tirage pour qu’elle échoue lorsque la branche protégée est mise à jour. Remettre en file d’attente une build pour actualiser l’état de la build. Ce paramètre garantit que les modifications apportées aux demandes de tirage sont correctement générés, même lorsque la branche protégée change. Cette option est optimale pour les équipes qui ont des branches importantes avec un volume inférieur de modifications. Les équipes travaillant dans des branches de développement très occupées peuvent trouver perturbant d'attendre la fin d'une compilation à chaque fois que la branche protégée est mise à jour.
    • Après n les heures de branch name mise à jour : cette option expire l’état actuel de la stratégie lorsque la branche protégée est miseà jour si la build passée est antérieure au seuil entré. Cette option est un compromis entre toujours exiger une build lorsque la branche protégée est mise à jour et n’en nécessite jamais. Ce choix est excellent pour réduire le nombre de builds lorsque votre branche protégée a des mises à jour fréquentes.
    • Jamais : les mises à jour de la branche protégée ne modifient pas l’état de la stratégie. Cette valeur réduit le nombre de builds de votre branche. Cela peut poser des problèmes lors de la fermeture de requêtes pull qui n'ont pas été mises à jour récemment.

  5. Entrez un nom d’affichage facultatif pour cette stratégie de build. Ce nom identifie la stratégie dans la page Stratégies de branche. Si vous ne spécifiez pas de nom d’affichage, la stratégie utilise le nom de définition de build.

  6. Sélectionnez Enregistrer.

Lorsque le propriétaire envoie les modifications qui sont générées avec succès, l’état de la stratégie est mis à jour. Si vous avez choisi une stratégie de build Immédiatement quand branch name est mise à jour ou Après n les heures si branch name a été mise à jour, le statut de la stratégie est mis à jour lorsque la branche protégée est mise à jour si la build la plus récente n’est plus valide.

Vérifications d'état

Les services externes peuvent utiliser l’API d’état de la demande de tirage pour publier un état détaillé sur vos demandes de tirage. La stratégie de branche pour les services supplémentaires permet à ces services externes de participer au workflow de PR et d'établir des exigences en matière de stratégie.

Capture d'écran de Require external services to approve (Exiger l'approbation des services externes).

Pour obtenir des instructions sur la configuration de cette stratégie, consultez Configurer une stratégie de branche pour un service externe.

Exiger l'approbation des services externes

Les services externes peuvent utiliser l’API d’état de la demande de tirage pour publier un état détaillé sur vos demandes de tirage. La stratégie de branche pour les services supplémentaires permet à ces services externes de participer au workflow des RP et d'établir des exigences en matière de politiques.

Exiger des services externes pour approuver

Pour obtenir des instructions sur la configuration de cette stratégie, consultez Configurer une stratégie de branche pour un service externe.

Inclure automatiquement les réviseurs du code

Vous pouvez ajouter automatiquement des réviseurs à des demandes de tirage qui modifient des fichiers dans des répertoires et des fichiers spécifiques, ou à toutes les demandes de tirage dans un dépôt.

  1. Sélectionnez le bouton + en regard de Réviseurs inclus automatiquement.

    Capture d’écran montrant Ajouter des réviseurs requis.

  2. Renseignez l’écran Ajouter une nouvelle stratégie de réviseur.

    Capture d’écran montrant l’écran Ajouter une nouvelle stratégie de réviseur.

    • Ajoutez des personnes et des groupes auxréviseurs.

    • Sélectionnez Facultatif si vous souhaitez ajouter automatiquement des réviseurs, mais ne nécessitent pas leur approbation pour terminer la demande de tirage.

      Vous pouvez également sélectionner Obligatoire si les demandes de tirage ne peuvent pas être terminées tant que :

      • Chaque personne ajoutée en tant que réviseur approuve les modifications.
      • Au moins une personne dans chaque groupe ajoutée en tant que réviseur approuve les modifications.
      • Si un seul groupe est requis, le nombre minimal de membres que vous spécifiez approuve les modifications.

    • Spécifiez les fichiers et dossiers qui nécessitent les réviseurs inclus automatiquement. Laissez ce champ vide pour demander aux réviseurs de toutes les demandes de tirage dans la branche.

    • Sélectionnez Autoriser les demandeurs à approuver leurs propres modifications si les propriétaires de demandes de tirage peuvent voter pour approuver leurs propres demandes de tirage pour satisfaire à cette stratégie.

    • Vous pouvez spécifier un message de flux d’activité qui apparaît dans la demande de tirage.

  3. Sélectionnez Enregistrer.

Notes

Cette fonctionnalité est disponible pour Azure DevOps Server 2020 et versions ultérieures.

Sélectionnez les réviseurs pour des répertoires et des fichiers spécifiques dans votre référentiel.

Entrez le chemin d’accès et les réviseurs requis

Ces réviseurs sont automatiquement ajoutés aux demandes de tirage qui modifient les fichiers le long de ces chemins. Vous pouvez également spécifier un message de flux d’activité.

Ajouter des réviseurs automatiques

Si vous sélectionnez Obligatoire, la demande de tirage ne peut pas être terminée tant que :

  • Chaque utilisateur ajouté en tant que réviseur pour le chemin approuve les modifications.
  • Au moins une personne de chaque groupe ajoutée au chemin d’accès approuve les modifications.
  • Le nombre de réviseurs spécifiés pour chaque groupe ajouté au chemin d’accès approuve les modifications.

Les réviseurs requis sont ajoutés automatiquement

Sélectionnez Facultatif si vous souhaitez ajouter automatiquement des réviseurs, mais ne nécessitent pas leur approbation pour terminer la demande de tirage.

Vous pouvez sélectionner les demandeurs peuvent approuver leurs propres modifications.

Lorsque tous les réviseurs requis approuvent le code, vous pouvez terminer la demande de tirage.

L’état de la demande de tirage indique que les réviseurs ont approuvé

Contourner les stratégies de branche

Dans certains cas, vous devrez peut-être contourner les exigences de stratégie. Les autorisations de contournement vous permettent d’envoyer des modifications à une branche directement ou d’effectuer des demandes de tirage qui ne répondent pas aux stratégies de branche. Vous pouvez accorder des autorisations de contournement à un utilisateur ou un groupe. Vous pouvez étendre les autorisations de contournement à un projet entier, à un référentiel ou à une seule branche.

Deux autorisations permettent aux utilisateurs de contourner la stratégie de branche de différentes manières :

  • Contourner les stratégies lors de l’exécution des demandes de tirage s’applique uniquement à l’achèvement de la demande de tirage. Les utilisateurs disposant de cette autorisation peuvent effectuer des demandes de tirage même si les demandes de tirage ne répondent pas aux stratégies.

  • Les stratégies de contournement lors de l’envoi s’appliquent aux envois à partir de référentiels locaux et aux modifications effectuées sur le web. Les utilisateurs disposant de cette autorisation peuvent envoyer des modifications directement aux branches protégées sans répondre aux exigences de stratégie.

Capture d’écran montrant les autorisations d’application de stratégie de contournement.

Pour plus d’informations sur la gestion de ces autorisations, consultez AutorisationsGit.

Dans TFS 2015 à TFS 2018 Update 2, l’autorisation Exempt de l’application de la stratégie permet aux utilisateurs disposant de cette autorisation d’effectuer les actions suivantes :

  • Accepter de remplacer les stratégies et de compléter une requête pull même si l'ensemble actuel des stratégies de la branche n'est pas satisfait.
  • Envoyer directement à une branche, même si des stratégies de branche sont définies. Lorsqu'un utilisateur disposant de cette permission effectue un push qui remplacerait la stratégie de la branche, le push contourne automatiquement la stratégie de la branche sans étape d'acceptation ou d'avertissement.

Important

Soyez prudent lorsque vous accordez la possibilité de contourner les stratégies, en particulier au niveau du référentiel et du projet. Les stratégies sont une pierre angulaire de la gestion du code source sécurisée et conforme.

Filtres de chemin

Plusieurs stratégies de branche offrent des filtres de chemin d’accès. Si un filtre de chemin d’accès est défini, la stratégie s’applique uniquement aux fichiers qui correspondent au filtre de chemin d’accès. Laisser ce champ vide signifie que la stratégie s’applique à tous les fichiers de la branche.

Vous pouvez spécifier des chemins absolus (le chemin doit commencer par / ou un caractère générique) et des caractères génériques. Exemples :

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Vous pouvez spécifier plusieurs chemins en utilisant ; comme séparateur. Exemple :

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Les chemins préfixés par ! sont exclus s’ils seraient autrement inclus. Exemple :

  • /WebApp/*;!/WebApp/Tests/* inclut tous les fichiers dans /WebApp, à l’exception des fichiers dans /WebApp/Tests
  • !/WebApp/Tests/* ne spécifie aucun fichier, car rien n’est inclus en premier

L’ordre des filtres est significatif. Les filtres sont appliqués de gauche à droite.

Questions & réponses

Puis-je envoyer des modifications directement aux branches qui ont des stratégies de branche ?

Vous ne pouvez pas pousser des changements directement vers des branches avec des stratégies de branche requises à moins que vous n'ayez la permission de contourner les politiques de branche. Les modifications apportées à ces branches ne peuvent être apportées qu’à l’aide de demandesde tirage. Vous pouvez envoyer des modifications directement aux branches qui ont des stratégies de branche facultatives, si elles n’ont aucune stratégie de branche requise.

Qu’est-ce que la saisie semi-automatique ?

Les demandes de tirage dans des branches avec des stratégies de branche configurées ont le bouton Définir la saisie semi-automatique. Sélectionnez cette option pour terminer automatiquement la demande de tirage une fois qu’elle répond à toutes les stratégies. La saisie semi-automatique est utile lorsque vous ne vous attendez pas à des problèmes avec vos modifications.

Quand les conditions de stratégie de branche sont-elles vérifiées ?

Les stratégies de branche sont réévaluées sur le serveur lorsque les propriétaires de demandes de tirage poussent les modifications et lorsque les réviseurs votent. Si une stratégie déclenche une build, l’état de la build est en attente jusqu’à la fin de la génération.

Puis-je utiliser des définitions de build XAML dans les stratégies de branche ?

Non, vous ne pouvez pas utiliser les définitions de build XAML dans les stratégies de branche.

Quels caractères génériques puis-je utiliser pour les réviseurs de code requis ?

Les astérisques * simples correspondent à n’importe quel nombre de caractères, y compris les barres obliques / et les barres obliques inverses\. Les points d’interrogation ? correspondent à n’importe quel caractère unique.

Exemples :

  • *.sql correspond à tous les fichiers avec l’extension .sql.
  • /ConsoleApplication/* correspond à tous les fichiers sous le dossier nommé ConsoleApplication.
  • /.gitattributes correspond au fichier .gitattributes* à la racine du référentiel.
  • */.gitignore correspond à n’importe quel fichier .gitignore dans le référentiel.

Les chemins d’accès du réviseur de code requis respectent-ils la casse ?

Non, les stratégies de branche ne respectent pas la casse.

Comment puis-je configurer plusieurs utilisateurs en tant que réviseurs requis, mais exiger qu’un seul d’entre eux approuve ?

Vous pouvez ajouter les utilisateurs à un groupe, puis ajouter le groupe en tant que réviseur. Tout membre du groupe peut ensuite approuver pour répondre à l’exigence de stratégie.

J’ai des autorisations de stratégie de contournement. Pourquoi les échecs de stratégie sont-ils toujours présents dans les statuts de demande de tirage ?

Les stratégies configurées sont toujours évaluées pour les modifications apportées aux demandes de tirage. Pour les utilisateurs disposant d’autorisations de contournement de stratégie, l’état de la stratégie signalée est consultatif uniquement. Si l’utilisateur disposant d’autorisations de contournement approuve, l’état d’échec ne bloque pas l’achèvement de la demande de tirage.

Pourquoi ne puis-je pas terminer mes propres demandes de tirage lorsque « Autoriser les demandeurs à approuver leurs propres modifications est défini » ?

La stratégie Exiger un nombre minimal de réviseurs et la stratégie Réviseurs inclus automatiquement ont toutes deux des options permettant d’autoriser les demandeurs à approuver leurs propres modifications. Dans chaque stratégie, le paramètre s’applique uniquement à cette stratégie. Le paramètre n’affecte pas l’autre stratégie.

Par exemple, votre demande de tirage a les stratégies suivantes définies :

  • Exiger un nombre minimal de réviseurs nécessite au moins un réviseur.
  • Les réviseurs inclus automatiquement nécessitent que vous ou une équipe que vous soyez en tant que réviseur.
  • Les réviseurs inclus automatiquement ont activé l’option Autoriser les demandeurs à approuver leurs propres modifications.
  • Exiger qu’un nombre minimal de réviseurs n’ait pas activé l’option Autoriser les demandeurs à approuver leurs propres modifications.

Dans ce cas, votre approbation satisfait automatiquement les réviseurs inclus, mais ne nécessite pas un nombre minimal de réviseurs, de sorte que vous ne pouvez pas terminer la demande de tirage.

Il peut également y avoir d’autres stratégies, telles que Interdire au pusher le plus récent d’approuver leurs propres modifications, qui vous empêchent d’approuver vos propres modifications même si l’option Autoriser les demandeurs à approuver leurs propres modifications est définie.

Que se passe-t-il lorsque le chemin d'accès dans les filtres de chemin d'accès ne commence pas par / ou par un caractère générique ?

Le chemin d'accès dans les filtres de chemin d'accès qui ne commence pas par / ou par un caractère générique n'a aucun effet, et le filtre de chemin d'accès est évalué comme si ce chemin d'accès n'avait pas été spécifié. Un tel chemin ne peut pas correspondre au / par lequel commence le chemin d'accès absolu au fichier.