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 « AUTOTITLE ».
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 « AUTOTITLE ».
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 « AUTOTITLE ».
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 ou fichier.
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 « AUTOTITLE ».
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 la branche principale, 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 AUTOTITLE.
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 AUTOTITLE.
- 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 AUTOTITLE.
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 « AUTOTITLE ».