Si vous êtes mainteneur de référentiel, vous pouvez gérer et standardiser les pull requests que les contributeurs créent dans votre référentiel de différentes 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 pull request
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 pull request pour votre dépôt ».
Vous pouvez utiliser des modèles de pull request pour normaliser le processus de révision de votre dépôt. Par exemple, vous pouvez inclure une liste de tâches que vous souhaitez que les auteurs terminent avant de fusionner leurs demandes de tirage afin que ces tâches soient intégrées 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 le corps de leur demande de tirage de sorte que la fusion de celle-ci 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 vous assurer qu’un membre de l’équipe de sécurité examine toujours les modifications apportées à votre fichier SECURITY.md ou dependabot.yml.
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 invités à effectuer une révision lorsque quelqu'un ouvre une pull request qui modifie les fichiers qu'ils possèdent. 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 une révision approuvée ou que toutes les vérifications d’état soient réussies. Consultez « À propos des branches protégées ».
Utilisation d’ensembles de règles
Les ensembles de règles, qui fonctionnent en même temps que les branches protégées, vous permettent d’appliquer des stratégies dans votre référentiel, telles que le passage des vérifications d’état ou de flux de travail avant qu’une demande de tirage (pull request) puisse être fusionnée.
Les ensembles de règles sont particulièrement utiles pour maintenir la sécurité des référentiels lorsqu’ils sont combinés à d’autres contrôles de sécurité automatisés. Par exemple :
- Vous pouvez utiliser des ensembles de règles pour appliquer l’action d’examens des dépendances, un flux de travail qui bloque les pull requests qui introduisent des dépendances vulnérables dans votre base de code. Consultez « Application de la révision des dépendances dans une organisation ».
- Si votre dépôt est configuré avec code scanning, vous pouvez utiliser des ensembles de règles pour définir la protection de fusion code scanning, ce qui empêche la fusion des pull requests s'il existe une alerte code scanning d'un certain niveau de gravité, ou si une analyse code scanning est toujours en cours. Consultez « Définir la protection contre la fusion d’analyse du code ».
Utilisation des règles 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'ensembles 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 détecter des problèmes mineurs, comme des fautes de frappe ou des problèmes de style, laisse plus de temps aux réviseurs pour se concentrer sur la substance d'un pull request.
Par exemple, vous pouvez utiliser GitHub Actions pour configurer des linters de code qui peuvent être exécutés sur des pull requests dans le cadre de votre flux de travail d’intégration continue (CI). Pour plus d’informations, consultez « Intégration continue ».