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 des ensembles de règles d’envoi (push)
Avec les règles de poussée, vous pouvez bloquer les poussées vers un référentiel privé ou interne et l'ensemble du réseau de fourches de ce référentiel en fonction de l'extension des fichiers, de la longueur des chemins d'accès aux fichiers, des chemins d'accès aux fichiers et aux dossiers et de la taille des fichiers.
Les règles de poussée ne nécessitent pas de ciblage de branche car elles s'appliquent à chaque poussée vers le référentiel.
Les ensembles de règles de poussée vous permettent de :
-
Restreindre les chemins d'accès aux fichiers : empêchez les commits qui incluent des changements dans les chemins de fichiers spécifiés d'être poussés.
Vous pouvez utiliser la syntaxe
fnmatchpour cela. Par exemple, une restriction ciblanttest/demo/**/*empêche toute poussée vers les fichiers ou dossiers du répertoiretest/demo/. Une restriction visanttest/docs/pushrules.mdempêche les poussées spécifiquement vers le fichierpushrules.mddans le répertoiretest/docs/. Pour plus d’informations, consultez « Création d’un ensemble de règles pour un dépôt ». -
Restreindre la longueur du chemin d'accès du fichier : empêchez les commits qui incluent des chemins d'accès de fichier qui dépassent une limite de caractères spécifiée d’être poussés.
-
Restreindre les extensions de fichier : empêchez les commits qui incluent des fichiers avec des extensions de fichier spécifiées d’être poussés.
-
Restreindre la taille du fichier : empêchez les commits qui dépassent une limite de taille de fichier spécifiée d'être poussés.
À propos des règles de poussée pour les référentiels fourchés
Les règles de poussée s’appliquent à l’ensemble du réseau de fourche d’un référentiel, ce qui garantit que chaque point d'entrée vers le référentiel est protégé. Par exemple, si vous fourchez un référentiel dont les règles de poussée sont activées, les mêmes règles de poussée s'appliqueront également à votre référentiel fourché.
Pour un référentiel fourché, les seules personnes ayant des permissions de contournement pour une règle de poussée sont celles qui ont des permissions de contournement dans le référentiel racine.
Pour plus d’informations, consultez « À propos des ensembles de règles ».
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 ».