Managing and standardizing pull requests

Use these steps to manage and standardize the pull requests that contributors create in your repository.

Dans cet article

If you are a repository maintainer, there are several ways that you can manage and standardize the pull requests that contributors create in your repository. These steps can help you ensure that pull requests are reviewed by the right people, and that they meet your repository's standards.

Using pull request templates

Pull request templates let you customize and standardize the information you'd like to be included when someone creates a pull request in your repository. When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body. For more information, see "Création d’un modèle de demande de tirage pour votre dépôt."

You can use pull request templates to standardize the review process for your repository. For example, you can include a list of tasks that you would like authors to complete before merging their pull requests, by adding a task list to the template. For more information, see "À propos des listes de tâches."

You can request that contributors include an issue reference in their pull request body, so that merging the pull request will automatically close the issue. For more information, see "Relier une demande de tirage à un problème."

Defining code owners

You may want to make sure that specific individuals always review changes to certain code or files in your repository. For example, you may want a technical writer on your team to always review changes in the docs directory.

You can define individuals or teams that you consider responsible for code or files in a repository to be code owners. Code owners will automatically be requested for review when someone opens a pull request that modifies the files that they own. You can define code owners for specific types of files or directories, as well as for different branches in a repository. For more information, see "À propos des propriétaires de code."

Using protected branches

You can use protected branches to prevent pull requests from being merged into important branches, such as main, until certain conditions are met. For example, you can require passing CI tests or an approving review. For more information, see "À propos des branches protégées."

Using push rulesets

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.

For more information, see "À propos des ensembles de règles."

Using automated tools to review code styling

Use automated tools, such as linters, in your repository's pull requests to maintain consistent styling and make code more understandable. Using automated tools to catch smaller problems like typos or styling leaves more time for reviewers to focus on the substance of a pull request.

For example, you can use GitHub Actions to set up code linters that can run on pull requests as part of your continuous integration (CI) workflow. For more information, see "À propos de l’intégration continue avec GitHub Actions."