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 de poussée pour 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.

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 d’GitHub Apps.

Pour les jeux de règles de poussée, 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 des ensembles de règles et d’autorisations de contournement, consultez « Création d’un ensemble 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 à revenir sur des 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 demande de tirage ».

Exiger que les déploiements réussissent 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 validations signées

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 envois (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.

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

Note

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 sur GitHub. 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 « Extraction de demandes de tirage 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

Note

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 dépôts ou les rôles personnalisés avec l’autorisation « modifier les règles de dépôt » 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 une poussée 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.

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 d’API REST pour les états 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. Quand 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.

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
Strictes	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 de dépannage, 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.

Restreindre les chemins d’accès aux fichiers

Empêchez les commit 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.

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