Meilleures pratiques pour les demandes de tirage

Meilleures pratiques pour créer des demandes de tirage

Lors de la création d’une demande de tirage, suivez quelques bonnes pratiques pour un processus de révision plus fluide. Pour plus d'informations sur la création d'une demande de tirage, voir « Création d’une demande de tirage.».

Écrire de petites demandes de tirage

Visez à créer de petites demandes de tirage ciblées qui répondent à un seul objectif. Les petites demandes sont plus faciles et plus rapides à examiner et à fusionner, elles laissent moins de place à l'introduction de bogues et fournissent un historique plus clair des modifications.

Révisez votre propre demande de tirage en premier

Révisez, générez et testez votre propre demande de tirage avant de l’envoyer. Cela vous permettra d’intercepter des erreurs ou des fautes de frappe que vous avez peut-être manquées avant que d’autres commencent à réviser.

Fournir un contexte et des conseils

Écrivez des titres et des descriptions clairs pour vos demandes de tirage afin que les réviseurs puissent rapidement comprendre ce que fait la demande de tirage. Dans le corps de la demande, spécifiez :

• l’objectif de la demande de tirage ;
• une vue d’ensemble de ce qui a changé ; et
• des liens vers du contexte supplémentaire, tels que le suivi des problèmes ou des conversations précédentes.

Pour aider les réviseurs, partagez le type de commentaires dont vous avez besoin. Par exemple, avez-vous besoin d'un examen rapide ou d'une critique plus approfondie ?

Si votre demande de tirage se compose de modifications apportées à plusieurs fichiers, fournissez des conseils aux réviseurs sur l’ordre dans lequel passer en revue les fichiers. Recommandez où commencer et comment procéder à la révision.

Meilleures pratiques pour la gestion des demandes de tirage

Si vous êtes un mainteneur de dépôt, procédez comme suit pour gérer et normaliser les demandes de tirage que les contributeurs créent dans votre référentiel.

Utilisez des 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éfinir des propriétaire 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 ».

Utilisez des 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 ».

Utiliser les ensembles de règles de poussées

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 fnmatch pour cela. Par exemple, une restriction ciblant test/demo/**/* empêche toute poussée vers les fichiers ou dossiers du répertoire test/demo/. Une restriction visant test/docs/pushrules.md empêche les poussées spécifiquement vers le fichier pushrules.md dans le répertoire test/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 ».

Utiliser des 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 ».