Règles disponibles pour les ensembles de règles

Vous pouvez créer des ensembles de règles de branche ou balise pour contrôler la façon dont les utilisateurs peuvent interagir avec une sélection de branches et d’étiquettes dans un référentiel. Vous pouvez également créer des ensembles de règles push pour bloquer les pushes vers un référentiel privé ou interne et l'ensemble du réseau de fourches de ce référentiel.

Lorsque vous créez un ensemble de règles, vous pouvez autoriser certains utilisateurs à contourner les règles de l’ensemble de règles. Il peut s’agir d’utilisateurs disposant de certains rôles, d’équipes spécifiques ou GitHub Apps.

Pour les ensembles de règles push, les autorisations de contournement s'appliquent à un référentiel et à l'ensemble du réseau de fourches du référentiel. Cela signifie que les seuls utilisateurs qui peuvent contourner cet ensemble de règles pour n’importe quel dépôt du réseau de fourche de ce référentiel sont les utilisateurs qui peuvent contourner cet ensemble de règles dans le référentiel racine.

Pour plus d’informations sur la création d'ensembles de règles et d’autorisations de contournement, consultez Création d'ensembles de règles pour un dépôt.

Limiter les créations

Si cette option est sélectionnée, seuls les utilisateurs disposant d’autorisations de contournement peuvent créer des branches ou des étiquettes dont le nom correspond au modèle que vous spécifiez.

Limiter les mises à jour

Si cette option est sélectionnée, seuls les utilisateurs disposant d’autorisations de contournement peuvent effectuer des poussées vers les branches ou les étiquettes dont le nom correspond au modèle que vous spécifiez.

Limiter les suppressions

Si cette option est sélectionnée, seuls les utilisateurs disposant d’autorisations de contournement peuvent supprimer les branches ou les étiquettes dont le nom correspond au modèle que vous spécifiez. Cette règle est sélectionnée par défaut.

Exiger un historique linéaire

L’application d’un historique de commits linéaire empêche les collaborateurs de pousser les commits de fusion vers les branches ou étiquettes ciblées. Cela signifie que toutes les demandes de tirage fusionnées dans la branche ou l’étiquette doivent utiliser une fusion « squash » ou « rebase ». Un historique de validation strictement linéaire peut aider les équipes à inverser les modifications plus facilement. Pour plus d’informations sur les méthodes de fusion, consultez À propos des fusions de demande de tirage.

Avant de pouvoir exiger un historique de validation linéaire, votre dépôt doit autoriser une fusion « squash » ou « rebase ». Pour plus d’informations, consultez « Configuration des fusions de pull request ».

Exiger la réussite des déploiements avant de fusionner

Vous pouvez exiger que des modifications aient été déployées avec succès dans des environnements spécifiques avant qu’une branche puisse être fusionnée. Par exemple, vous pouvez utiliser cette règle pour vous assurer que les modifications ont été déployées avec succès dans un environnement intermédiaire avant la fusion des modifications dans votre branche par défaut.

Exiger des commits signés

Lorsque vous activez la signature de validation requise sur une branche, des contributeurs et des bots ne peuvent envoyer (push) à la branche que des validations signées et vérifiées. Pour plus d’informations, consultez « À propos de la vérification des signatures de commit ».

Les règles et ensembles de règles de protection des branches se comportent différemment lorsque vous créez une branche : avec les ensembles de règles, seules les validations qui ne sont pas accessibles depuis d’autres branches sont vérifiées, alors qu’avec les règles de protection des branches, les validations signées ne sont pas vérifiées, sauf si vous limitez les push qui créent des branches correspondantes. Dans les deux cas, lorsque vous mettez à jour une branche, toutes les validations de la plage spécifiée sont vérifiées, même si une validation est accessible à partir d’autres branches.

Dans les deux méthodes, nous utilisons verified_signature? pour confirmer si une validation présente une signature valide. Si ce n’est pas le cas, la mise à jour n’est pas acceptée.

Remarque

Si vous avez activé le mode vigilant dans vos paramètres de compte, ce qui indique que vos commits seront toujours signés, tous les commits que GitHub identifie comme « Partiellement vérifiés » sont autorisés sur les branches exigeant des commits signés. Pour plus d’informations sur le mode vigilant, consultez Affichage des états de vérification pour tous vos commits.
Si un collaborateur envoie (push) une validation non signée à une branche qui exige des signatures de validation, ce collaborateur devra rebaser la validation pour inclure une signature vérifiée, puis effectuer un envoi (push) forcé de la validation réécrite à la branche.

Vous pouvez toujours envoyer (push) des validations locales à la branche si elles sont signées et vérifiées. Vous pouvez également fusionner des validations signées et vérifiées dans la branche à l’aide d’une demande de tirage. En revanche, vous ne pouvez pas effectuer de « squash and merge » sur une demande de tirage dans la branche sur GitHub, sauf si vous en êtes l’auteur. Vous pouvez effectuer un « squash » sur des demandes de tirage et les fusionner localement. Pour plus d’informations, consultez « Consulter des pull requests localement ».

Pour plus d’informations sur les méthodes de fusion, consultez À propos des méthodes de fusion sur GitHub.

Exiger une demande de tirage avant la fusion

Vous pouvez exiger que toutes les modifications apportées à la branche cible soient associées à une demande de tirage. La demande de tirage n’a pas nécessairement besoin d’être approuvée, mais elle doit être ouverte.

Paramètres supplémentaires

Remarque

Si vous sélectionnez Ignorer les approbations de demandes de tirage obsolètes lorsque de nouveaux commits sont poussés et/ou Demander l’approbation de la poussée révisable la plus récente, la création manuelle du commit de fusion pour une demande de tirage (pull request) et sa poussée (push) directement vers une branche protégée échouent, sauf si le contenu de la fusion correspond exactement à la fusion générée par GitHub pour la demande de tirage.

En outre, avec ces paramètres, l’approbation des révisions est ignorée comme obsolète si la base de fusion introduit de nouvelles modifications après l’envoi de la révision. La base de fusion est le commit qui est le dernier ancêtre commun entre la branche de rubrique et le branche de base. Si la base de fusion change, la demande de tirage ne peut pas être fusionnée tant que quelqu’un n’a pas approuvé à nouveau le travail.

Les administrateurs de référentiels ou les rôles personnalisés avec l’autorisation « modifier les règles de référentiel » peuvent exiger que toutes les demandes de tirage reçoivent un nombre spécifique de révisions d’approbation avant qu’une personne ne fusionne la demande de tirage dans une branche protégée. Vous pouvez demander des révisions d’approbation à des personnes qui ont des autorisations d’écriture sur le dépôt ou à un propriétaire de code désigné.

Si vous activez les révisions requises, les collaborateurs peuvent pousser les modifications vers une branche uniquement via une demande de tirage approuvée par le nombre requis de réviseurs disposant d’autorisations d’écriture.

Si une personne choisit l’option Demander des modifications dans une révision, elle doit approuver la demande de tirage avant que celle-ci puisse être fusionnée. Si un réviseur qui demande des modifications sur une demande de tirage n’est pas disponible, toute personne disposant d’autorisations d’écriture sur le dépôt peut ignorer la révision bloquante.

Même si tous les réviseurs obligatoires ont approuvé une demande de tirage, les collaborateurs ne peuvent pas fusionner la demande de tirage si d’autres demandes de tirage ouvertes ont une branche principale qui pointe vers le même commit avec des révisions en attente ou rejetées. Une personne avec des autorisations d’écriture doit d’abord approuver ou ignorer la révision bloquante sur les autres demandes de tirage.

Si vous le souhaitez, vous pouvez choisir d’ignorer les approbations de demande de tirage obsolètes lorsque des commits sont poussés et affectent le diff dans la demande de tirage. GitHub enregistre l’état du diff au moment où une demande de tirage est approuvée. Cet état représente l’ensemble des modifications approuvées par le réviseur. Si le diff sort de cet état (par exemple, parce qu’un contributeur pousse de nouvelles modifications vers la branche de demande de tirage ou clique sur Mettre à jour la branche, ou parce qu’une demande de tirage associée est fusionnée dans la branche cible), la révision d’approbation est ignorée car considérée comme obsolète et la demande de tirage ne peut pas être fusionnée tant qu’une personne n’approuve pas une nouvelle fois le travail. Pour plus d’informations sur la branche cible, consultez À propos des demandes de tirage (pull requests).

Si vous le souhaitez, vous pouvez choisir d’exiger des révisions des propriétaires de code. Dans ce cas, toute demande de tirage modifiant du contenu avec un propriétaire de code doit être approuvée par celui-ci avant qu’elle puisse être fusionnée dans la branche protégée. Notez que si le code a plusieurs propriétaires, l’approbation de n’importe lequel d’entre eux sera suffisante pour satisfaire à cette exigence. Pour plus d’informations, consultez « À propos des propriétaires de code ».

Si vous le souhaitez, vous pouvez exiger une approbation d’une autre personne que la dernière personne qui effectue un push vers une branche avant qu’une demande de tirage puisse être fusionnée. Cela signifie qu’au moins un autre réviseur autorisé approuve les modifications. Par exemple, le « dernier réviseur » peut vérifier que le dernier ensemble de modifications incorpore les commentaires d’autres révisions et n’ajoute pas de nouveau contenu non révisé.

Pour les demandes de tirage complexes qui nécessitent de nombreuses révisions, exiger l’approbation d’une personne autre que la dernière personne qui réalise la poussée peut être un compromis qui évite d’avoir à ignorer toutes les révisions obsolètes : avec cette option, les révisions « obsolètes » ne sont pas ignorées et la demande de tirage reste approuvée tant que quelqu’un d’autre que la personne qui a apporté les modifications les plus récentes l’approuve. Les utilisateurs qui ont déjà révisé une demande de tirage peuvent effectuer une nouvelle approbation après la poussée la plus récente pour répondre à cette exigence. Si vous craignez que les demandes de tirage soient « détournées » (où que du contenu non approuvé soit ajouté aux demandes de tirage approuvées), il est plus sûr d’ignorer les révisions obsolètes.

Si vous le souhaitez, vous pouvez exiger que tous les commentaires sur la demande de tirage soient résolus avant que celle-ci puisse être fusionnée dans une branche. Cela garantit que tous les commentaires ont été traités ou ont fait l’objet d’un accusé de réception avant la fusion.

Si vous le souhaitez, vous pouvez exiger un type de fusion : fusionner, squashing ou rebaser. Cela signifie que les branches ciblées peuvent uniquement être fusionnées selon le type autorisé. En outre, si le référentiel a désactivé une méthode de fusion et que l’ensemble de règles nécessite une méthode différente, la fusion sera bloquée. Consultez « À propos des méthodes de fusion sur GitHub ».

Réviseurs obligatoires

Si désiré, vous pouvez demander une révision ou une approbation par des équipes spécifiques lorsqu'un pull request modifie certains fichiers ou répertoires. Vous pouvez spécifier jusqu’à 15 équipes différentes, et pour chaque équipe, vous pouvez exiger un certain nombre d’approbations des membres de l’équipe.

La liste déroulante Réviseur vous permet de sélectionner toute équipe qui se trouve dans l’étendue où la règle est définie.

        **Règles à l’échelle** de l’organisation : l’équipe doit appartenir à l’organisation.

        **Règles au niveau du référentiel** : l’équipe doit appartenir à l’organisation propriétaire du référentiel.

Cette règle n’est pas disponible sur les référentiels appartenant à l’utilisateur, car elles ne contiennent pas d’équipes.

Les approbations requises peuvent être définies de 0 (zéro) à 10. Ne nécessiter aucune approbation signifie que l’équipe sera ajoutée à des fins de visibilité, mais l’équipe n’a pas besoin d’approuver la demande.

Pour chaque équipe, vous pouvez spécifier une liste de modèles de fichiers qui déterminent les fichiers auxquels le paramètre s’applique. Le format de cette liste de fichiers est le même qu’un fichier standard .gitignore :

Un modèle commençant par un point d’exclamation (!) est une négation. Cela fera en sorte que les chemins correspondant aux modèles antérieurs ne nécessiteront pas d’approbations.
Les modèles sont vérifiés dans l'ordre, de sorte que les modèles négatifs peuvent empêcher des fichiers de correspondre aux règles précédentes.

Exiger la réussite des vérifications d'état avant de fusionner

Les vérifications d’état requises garantissent que tous les tests CI requis ont réussi avant que des collaborateurs puissent apporter des modifications à une branche ou une étiquette ciblée par votre ensemble de règles. Les vérifications d’état requises peuvent être des vérifications ou des états. Pour plus d’informations, consultez « À propos des vérifications d’état ».

Vous pouvez utiliser l’API d’état de commit pour autoriser les services externes à marquer les commits avec un état approprié. Pour plus d’informations, consultez « Points de terminaison de l’API REST pour les statuts de commit ».

Une fois que des vérifications d’état requises sont activées, elles doivent toutes réussir avant que des collaborateurs puissent fusionner des modifications dans la branche ou l’étiquette.

Toute personne ou intégration disposant d’autorisations d’écriture sur un dépôt peut définir l’état de toute vérification d’état dans le dépôt. Toutefois, dans certains cas, vous voudrez peut-être accepter uniquement la vérification d’état d’une GitHub App spécifique. Lorsque vous ajoutez une règle de vérification d’état requise, vous pouvez sélectionner une application comme source prévue des mises à jour d’état. L’application doit être installée dans le dépôt avec l’autorisation statuses:write, doit avoir récemment soumis une exécution des vérifications et doit être associée à une vérification d’état requise préexistante dans l’ensemble de règles. Si l’état est défini par une autre personne ou intégration, la fusion n’est pas autorisée. Si vous sélectionnez « Toute source », vous pouvez toujours vérifier manuellement l’auteur de chaque état, répertorié dans la zone de fusion.

Pour résoudre les problèmes liés à la configuration des contrôles d'état dans les ensembles de règles, consultez Résolution des problèmes de règles.

Vous pouvez considérer les vérifications d’état requises comme « lâches » ou « strictes ». Le type de vérification d’état requise que vous choisissez détermine si votre branche doit être à jour avec la branche de base avant de la fusion.

Type de vérification d’état requise	Paramètre	Exigences pour la fusion	Considérations

          **Strict** | La case à cocher **Exiger que les branches soient à jour avant la fusion** est activée. | La branche de rubrique **doit** être à jour avec la branche de base avant la fusion. | Il s’agit du comportement par défaut pour les vérifications d’état requises. D’autres builds peuvent être requises, car vous devez mettre à jour la branche principale une fois que les autres collaborateurs ont mis à jour la branche cible.|

| Lâches | La case à cocher Exiger que les branches soient à jour avant la fusion n’est pas activée. | La branche ne doit pas être à jour avec la branche de base avant la fusion. | Vous aurez moins de builds requises, car vous n’aurez pas besoin de mettre à jour la branche principale après que d’autres collaborateurs auront fusionné des demandes de tirage. Des vérifications d’état peuvent échouer après que vous avez fusionné votre branche s’il existe des modifications incompatibles avec la branche de base. | | Désactivé | La case à cocher Exiger la réussite des vérifications d’état avant de fusionner n’est pas activée. | La branche n’a aucune restriction de fusion. | Si les vérifications d’état requises ne sont pas activées, des collaborateurs peuvent fusionner la branche à tout moment, qu’elle soit ou non à jour avec la branche de base. Cela augmente la possibilité de modifications incompatibles.

Pour obtenir des informations sur le dépannage des contrôles d'état, consultez Résolution des problèmes liés aux vérifications de statut requises.

Bloquer les poussées forcées

Vous pouvez empêcher les utilisateurs de forcer les poussées vers les branches ou étiquettes ciblées. Cette règle est activée par défaut.

Si quelqu’un force les poussées vers une branche ou une étiquette, les commits sur lesquels les autres collaborateurs ont basé leur travail peuvent être supprimés de l’historique de la branche ou de l’étiquette. Cela peut entraîner des conflits de fusion ou des demandes de tirage endommagées. Une poussée forcée peut également être utilisée pour supprimer des branches ou pointer une branche vers des commits qui n’ont pas été approuvés dans une demande de tirage.

L’activation des poussées forcées ne remplace aucune autre règle. Par exemple, si une branche nécessite un historique de validation linéaire, vous ne pouvez envoyer (push) de force des validations de fusion à cette branche.

Nécessite les résultats d’code scanning

Si vos référentiels sont configurés avec code scanning, vous pouvez utiliser des ensembles de règles pour empêcher la fusion des demandes de tirage lorsque l’une des conditions suivantes est remplie :

Un outil requis détecte une alerte code scanning dont la gravité est spécifiée dans l’ensemble de règles.
L’analyse d’un outil requis est toujours en cours.
Un outil requis n’est pas configuré pour le référentiel.

Pour plus d’informations, consultez « Définir la protection contre la fusion d’analyse du code ». Pour plus d’informations sur code scanning, consultez À propos de l’analyse du code.

Exiger des résultats de qualité du code

Si vos référentiels sont configurés avec GitHub Code Quality, vous pouvez utiliser des règles pour empêcher la fusion des pull requests lorsque l’une des conditions suivantes est remplie :

L’analyse est toujours en cours.
L’analyse échoue pour une raison quelconque, par exemple : vous avez épuisé votre budget pour les minutes d’actions.
Code Quality a trouvé un résultat d’une gravité du niveau défini dans l’ensemble de règles ou d’une gravité plus élevée.

Pour plus d’informations, consultez « À propos de la qualité du code GitHub » et « Définition des seuils de qualité du code pour les pull requests ».

Restreindre les chemins d’accès aux fichiers

Empêchez les commits qui incluent des modifications dans les chemins d'accès vers des fichiers spécifiés d'être poussés vers le référentiel. La limite est de 200 entrées et jusqu’à 200 caractères dans chaque entrée.

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