# Gestion et standardisation des pull requests

Gérez et standardisez les pull requests à l’aide de modèles, de responsables du code, de branches protégées, d’ensembles de règles et d’outils automatisés pour garantir des contributions au dépôt cohérentes et sécurisées.

Si vous maintenez un référentiel, vous pouvez utiliser les GitHub fonctionnalités pour rendre les pull requests plus cohérentes et plus faciles à examiner. La normalisation permet aux contributeurs de savoir quelles informations fournir, aide les réviseurs à se concentrer sur les bonnes modifications et contribue à protéger les branches importantes contre les fusions accidentelles ou risquées.

## Utilisation de modèles de pull request

Les modèles de pull request aident les contributeurs à fournir le contexte nécessaire à l’examen de votre projet. Un modèle peut inviter les auteurs à expliquer l’objectif de la modification, de lier des problèmes, d’inclure des notes de test ou d’effectuer une liste de contrôle avant de demander une révision.

Les modèles sont utiles lorsque de nombreux contributeurs ouvrent des pull requests ou lorsque votre projet comporte des exigences en matière de révision qui doivent être visibles à chaque fois. Consultez [Création d’un modèle de pull request pour votre dépôt](/fr/enterprise-server@3.20/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository), [À propos des listes de tâches](/fr/enterprise-server@3.20/get-started/writing-on-github/working-with-advanced-formatting/about-tasklists) et [Relier une demande de tirage à un problème](/fr/enterprise-server@3.20/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue).

## Définition des propriétaires de code

Les propriétaires de code identifient les personnes ou les équipes responsables des fichiers ou répertoires spécifiques. Lorsqu’une pull request modifie du code dont les propriétaires sont définis, GitHub peut demander automatiquement une révision aux propriétaires concernés.

Les responsables du code aident à orienter les demandes de révision vers les personnes ayant le contexte nécessaire. Ils sont particulièrement utiles pour les domaines sensibles tels que les fichiers de sécurité, la configuration du déploiement ou les bibliothèques partagées. Consultez « [À propos des propriétaires de code](/fr/enterprise-server@3.20/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) ».

## Utilisation de branches protégées

Les branches protégées permettent de conserver des branches importantes, telles que `main`, stables. Ils peuvent exiger des conditions telles que la réussite des vérifications d’état, des commits signés ou des revues approuvées avant qu’une pull request puisse être fusionnée.

Utilisez des branches protégées lorsqu’une branche représente du code de production, une ligne de mise en production ou une autre source importante de vérité. Consultez « [À propos des branches protégées](/fr/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) ».

## Utilisation d’ensembles de règles

Les jeux de règles vous permettent d’appliquer des règles du dépôt aux branches et aux balises. Ils peuvent exiger des vérifications d’état, des flux de travail, des revues de pull requests ou d’autres conditions avant que les modifications soient acceptées.

Les ensembles de règles sont utiles lorsque vous souhaitez des règles cohérentes entre plusieurs branches ou lorsque vous souhaitez combiner les exigences de révision avec des vérifications de sécurité automatisées, telles que la révision des dépendances ou code scanning la protection de fusion. Consultez [À propos des ensembles de règles](/fr/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets), [Application de la révision des dépendances dans une organisation](/fr/enterprise-server@3.20/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review) et [Définir la protection contre la fusion d’analyse du code](/fr/enterprise-server@3.20/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/set-merge-protection).

## 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 `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'ensembles de règles pour un dépôt](/fr/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax) ».
* **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.

Les ensembles de règles push permettent de bloquer le contenu à risque avant d’entrer dans le référentiel. Consultez « [À propos des ensembles de règles](/fr/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets) ».

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

Les outils automatisés, tels que les linters et les outils de formatage, aident à maintenir un style de code cohérent d’une pull request à l’autre. Ils peuvent intercepter automatiquement de petits problèmes afin que les réviseurs puissent se concentrer sur la conception, la exactitude et la maintenance.

Vous pouvez exécuter ces outils dans le cadre d’un workflow d’intégration continue avec GitHub Actions. Consultez « [Intégration continue](/fr/enterprise-server@3.20/actions/get-started/continuous-integration) ».