À propos des pull requests

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

Les demandes de tirage (pull request) permettent de modifier, de passer en revue et de fusionner du code dans un Référentiel Git sur Azure Repos. Les demandes de tirage peuvent provenir de branches dans le même référentiel ou à partir de branches dans des duplications (fork) du référentiel. Teams utilise des demandes de tirage pour passer en revue le code et fournir des commentaires sur les modifications avant de fusionner le code dans la branche primaire. Les réviseurs peuvent parcourir les modifications proposées, laisser des commentaires et voter pour approuver ou rejeter le code.

Pour obtenir des conseils complets sur la protection des référentiels pendant les demandes de tirage via des stratégies de branche, le contrôle d’accès et la vérification de validation, consultez Référentiels sécurisés et demandes de tirage.

Cet article décrit les guidelines de pull request et les implications de gestion. Pour obtenir des instructions sur la création, l’affichage, la révision et l’exécution des demandes de tirage, consultez les articles suivants :

Remarque

Pour des raisons de performance et de stabilité, le nombre de réviseurs qui peuvent être ajoutés à une pull request doit être inférieur ou égal à 1 000. Les nouvelles pull requests ne seront pas créées si vous ajoutez plus de 1 000 réviseurs, et les pull requests existantes ne vous permettront pas d'ajouter plus de 1 000 réviseurs.

Conseil / Astuce

Vous pouvez utiliser l’IA pour faciliter les tâches Azure DevOps. Consultez Activer l’aide à l’IA avec le serveur MCP Azure DevOps pour commencer.

Autorisations et conditions préalables

  • Les dépôts doivent être activés sur votre projet. Si le hub Repos et les pages associées ne s’affichent pas, consultez Activer ou désactiver un service Azure DevOps pour réactiver Repos.

  • Pour afficher ou passer en revue les PR (pull-requests), vous devez être membre d’un projet Azure DevOps avec au moins accès de base (Basic).

  • Pour contribuer à une demande de tirage, vous devez être membre du groupe de sécurité Lecteurs (Readers) ou disposer des autorisations correspondantes.

  • Pour créer et terminer une demande de tirage, vous devez être membre du groupe de sécurité Contributeurs (Contributors) ou disposer des autorisations correspondantes.

Remarque

Pour les projets publics, les utilisateurs autorisés à accéder aux Parties prenantes ont un accès complet à Azure Repos.

  • Les dépôts doivent être activés sur votre projet. Si le hub Repos et les pages associées ne s’affichent pas, consultez Activer ou désactiver un service Azure DevOps pour réactiver Repos.
  • Pour afficher ou passer en revue les PR (pull-requests), vous devez être membre d’un projet Azure DevOps avec au moins accès de base (Basic). Si vous n’êtes pas membre du projet, soyez ajouté.
  • Pour contribuer à une demande de tirage, vous devez être membre du groupe de sécurité Lecteurs (Readers) ou disposer des autorisations correspondantes.
  • Pour créer et terminer une demande de tirage, vous devez être membre du groupe de sécurité Contributeurs (Contributors) ou disposer des autorisations correspondantes.

Pour plus d'informations sur les permissions et l'accès, voir Permissions par défaut du référentiel et de la branche Git et À propos des niveaux d'accès.

Commentaires de qualité pour les demandes de tirage

Les revues de haute qualité commencent par des commentaires de haute qualité. Voici quelques clés pour obtenir de bons feedbacks sur les PR :

  • Le propriétaire de la demande de tirage doit disposer des bonnes personnes pour passer en revue la demande de tirage et s’assurer que les réviseurs savent ce que fait le code.
  • Les réviseurs doivent fournir des commentaires exploitables et constructifs.
  • Les propriétaires et les réviseurs doivent commenter et répondre rapidement.

Les propriétaires de demandes de tirage doivent :

  • Veiller à sélectionner les réviseurs appropriés à affecter à une demande de tirage.
  • Inclure les réviseurs qui connaissent le fonctionnement du code.
  • Demander aux développeurs de travailler dans d’autres zones pour partager leurs idées.
  • Donner une description claire des modifications.
  • Donner des conseils aux réviseurs à l'aide de modèles de pull request.
  • Fournir une build du code avec le correctif ou la fonctionnalité en cours d’exécution.
  • Répondre aux commentaires, accepter la suggestion ou expliquer pourquoi la modification suggérée n’est pas idéale.
  • Pour obtenir de bonnes suggestions en dehors de l’étendue de la demande de tirage, créez de nouveaux éléments de travail, des branches et des demandes de tirage pour effectuer ces modifications.

Les réviseurs doivent effectuer les tâches suivantes :

  • fournir une retour d'expérience sur les modifications avec lesquelles ils ne sont pas d'accord ;
  • identifier les problèmes et faire des suggestions spécifiques sur ce qu'il faut faire différemment ;
  • Assurez-vous que les retours d'expérience visent une intention claire et sont faciles à comprendre.
  • Laisser des commentaires ou voter sur les modifications

Pour plus d'informations, consultez Obtenir des retour d'expériences avec les demande de tirage (pull request) Git.

Politiques de branche et pull requests

Votre équipe peut s’appuyer sur des branches critiques dans votre référentiel, telles que la branche main, pour qu’elles soient toujours en bon état. Vous pouvez définir des stratégies de branche pour exiger des demandes de tirage pour toute modification sur ces branches protégées et rejeter les modifications envoyées (push) directement aux branches.

Vous pouvez ajouter d’autres stratégies aux demandes de tirage pour appliquer une meilleure qualité du code dans les branches clés. Des exigences supplémentaires comme une compilation propre du code proposé ou l’approbation de plusieurs examinateurs peuvent contribuer à protéger les branches clés.

Vous pouvez définir le nombre d’approbations requises pour une demande de tirage dans une stratégie de branche. Vous pouvez également définir certains réviseurs comme obligatoires ou facultatifs pour toutes ou certaines demandes de tirage. Une demande de tirage peut être définie sur la saisie semi-automatique avec le nombre d’approbations requis, même si d’autres réviseurs rejettent les modifications. Toutefois, les réviseurs requis doivent approuver les demandes de tirage avant que les demandes de tirage puissent être fusionnées. Il est recommandé qu’au moins deux personnes passent en revue et approuvent les modifications apportées à une demande de tirage importante.

Pour réinitialiser les votes chaque fois qu’un auteur de demande de tirage envoie (push) de nouvelles modifications, sélectionnez Réinitialiser les votes du réviseur de code lorsqu’il y a de nouvelles modifications dans la stratégie de branche Exiger un nombre minimal de réviseurs.

Le tableau suivant récapitule les stratégies que vous pouvez définir pour personnaliser une branche. Pour obtenir une vue d’ensemble de tous les paramètres et stratégies de référentiel et de branche, consultez les Paramètres et stratégies du référentiel Git.

Stratégie

Par défaut

Description

Demander un nombre minimal de réviseurs

Désactivé

Exiger l'approbation d'un certain nombre de réviseurs sur les pull requests.

Rechercher les éléments de travail liés

Désactivé

Encouragez la traçabilité en vérifiant les éléments de travail liés sur les pull requests

Vérifier la résolution des commentaires

Désactivé

Vérifiez que tous les commentaires ont été résolus pour les pull requests.

Limiter les types de fusion

Désactivé

Contrôlez l'historique des branches en limitant les types de fusion disponibles une fois que les pull requests ont été complétées.

Ajouter des stratégies de validation de build

Désactivé

Ajoutez une ou plusieurs stratégies pour valider le code en pré-fusionnant et en créant des modifications de demande de tirage. Peut également activer ou désactiver des stratégies.

Ajouter des stratégies de vérification d’état

Désactivé

Ajoutez une ou plusieurs stratégies pour exiger que d’autres services publient un statut de réussite pour compléter les pull requests. Peut également activer ou désactiver des stratégies.

Réviseurs inclus automatiquement

Désactivé

Ajoutez une ou plusieurs stratégies pour désigner les réviseurs de code à inclure automatiquement lorsque les demandes de tirage modifient certaines zones de code. Peut également activer ou désactiver des stratégies.

Pour plus d'informations, consultez les pages suivantes :

Définissez des vérifications de statut pour améliorer la qualité du code

Les pull requests et les règles de branche permettent aux équipes d’appliquer les meilleures pratiques pour examiner le code et exécuter des compilations automatisées. De nombreuses équipes ont d’autres exigences et validations à effectuer sur le code. Pour répondre à ces besoins, vous pouvez intégrer des vérifications d'état de demande de tirage dans le flux de travail de demande de tirage. Avec les vérifications d'état de demande de tirage, les services externes peuvent approuver par programmation les modifications de code en associant des informations de réussite ou d’échec aux demandes de tirage.

Pour plus d’informations, consultez les articles suivants :

Problème de base de fusion multiple

Dans certains cas, une demande de tirage possède plus d’une véritable base de fusion, et cette situation peut entraîner des problèmes de sécurité. Si les fichiers de la demande de tirage ont des versions différentes entre les bases de fusion, un avertissement de base de fusion multiple se produit. Pour plus d’informations et de rectification, consultez Multiples bases de fusion.

Étapes suivantes

  • Last updated on