Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-09-25. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Gestion et normalisation des demandes de tirage

Suivez ces étapes pour gérer et normaliser les demandes de tirage que les contributeurs créent dans votre référentiel.

Si vous êtes mainteneur de dépôt, vous pouvez gérer et normaliser les demandes de tirage que les contributeurs créent dans votre référentiel de plusieurs manières. Ces étapes peuvent vous aider à vous assurer que les demandes de tirage sont passées en revue par les bonnes personnes et qu’elles répondent aux normes de votre référentiel.

Utilisation de modèles de demande de tirage

Les modèles de demande de tirage vous permettent de personnaliser et de normaliser les informations que vous souhaitez inclure lorsque quelqu’un crée une demande de tirage dans votre référentiel. Quand vous ajoutez un modèle de demande de tirage (pull request) à votre dépôt, les contributeurs du projet voient automatiquement le contenu de ce modèle dans le corps de la demande de tirage. Pour plus d’informations, consultez « Création d’un modèle de demande de tirage pour votre dépôt ».

Vous pouvez utiliser des modèles de demande de tirage pour normaliser le processus de révision de votre référentiel. Par exemple, vous pouvez inclure une liste de tâches que vous souhaitez que les auteurs terminent avant de fusionner leurs demandes de tirage en ajoutant une liste de tâches au modèle. Pour plus d’informations, consultez « À propos des listes de tâches ».

Vous pouvez demander que les contributeur incluent une référence de problème dans leur corps de demande de tirage, afin que la fusion de la demande de tirage clôture automatiquement le problème. Pour plus d’informations, consultez « Relier une demande de tirage à un problème ».

Définition des propriétaires de code

Vous souhaiterez peut-être vous assurer que des personnes spécifiques passent toujours en revue les modifications apportées à certains fichiers ou code dans votre référentiel. Par exemple, vous souhaiterez peut-être qu’un rédacteur technique de votre équipe examine toujours les modifications dans le docs répertoire.

Vous pouvez définir les personnes ou les équipes que vous considérez comme responsables du code ou des fichiers d'un référentiel comme étant des propriétaires de code. Les propriétaires de code seront automatiquement sollicités pour une révision lorsque quelqu'un ouvre une demande de tirage qui modifie les fichiers dont ils sont propriétaires. Vous pouvez définir des propriétaires de code pour des types spécifiques de fichiers ou de répertoires, ainsi que pour différentes branches dans un référentiel. Pour plus d’informations, consultez « À propos des propriétaires de code ».

Utilisation de branches protégées

Vous pouvez utiliser des branches protégées pour empêcher la fusion des demandes de tirage dans des branches importantes, telles que main, jusqu’à ce que certaines conditions soient remplies. Par exemple, vous pouvez exiger la réussite de tests CI ou d’une révision approuvée. Pour plus d’informations, consultez « À propos des branches protégées ».

Utilisation d’outils automatisés pour passer en revue le style du code

Utilisez des outils automatisés, tels que des linters, dans les demandes de tirage de votre référentiel pour maintenir un style cohérent et rendre le code plus compréhensible. L’utilisation d’outils automatisés pour intercepter des problèmes plus petits comme les fautes de frappe ou le style laisse plus de temps aux réviseurs de se concentrer sur la substance d’une demande de tirage.

Par exemple, vous pouvez utiliser GitHub Actions pour configurer des linters de code qui peuvent s’exécuter sur des demandes de tirage dans le cadre de votre flux de travail d’intégration continue (CI). Pour plus d’informations, consultez « À propos de l’intégration continue avec GitHub Actions ».