Création d'ensembles de règles pour un dépôt

Vous pouvez ajouter des ensembles de règles à un dépôt pour contrôler la façon dont les utilisateurs peuvent interagir avec des branches et des étiquettes spécifiques.

Qui peut utiliser cette fonctionnalité ?

Toute personne disposant d’un accès en lecture à un dépôt peut voir les ensembles de règles du dépôt. Les personnes disposant d’un accès administrateur à un référentiel, ou d’un rôle personnalisé avec l’autorisation « modifier les règles du référentiel », peuvent créer, modifier et supprimer des ensembles de règles pour un référentiel et consulter les aperçus des ensembles de règles. Pour plus d’informations, consultez « À propos des rôles de référentiel personnalisés ».

Les ensembles de règles sont disponibles dans les dépôts publics avec GitHub Free et GitHub Free pour les organisations, et dans les dépôts publics et privés avec GitHub Pro, GitHub Team et GitHub Enterprise Cloud.

Les ensembles de règles de poussée sont disponibles pour le plan GitHub Enterprise Cloud dans les référentiels internes et privés, les fourches de référentiels dont les ensembles de règles de poussée sont activés, et les organisations de votre entreprise.

Dans cet article

Présentation

Vous pouvez créer des ensembles de règles pour contrôler la façon dont les utilisateurs peuvent interagir avec une sélection de branches et d’étiquettes dans un dépôt. Vous pouvez contrôler par exemple qui peut pousser les commits vers une certaine branche, la façon dont les commits doivent être mis en forme, ou qui peut supprimer ou renommer une étiquette. Vous pouvez également empêcher les utilisateurs de renommer les dépôts.

Lorsque vous créez un ensemble de règles, vous pouvez autoriser certains utilisateurs à contourner les règles de l’ensemble de règles.

Pour plus d'informations sur les ensembles de règles, consultez À propos des ensembles de règles.

Pour les clients disposant d'abonnements GitHub Team et GitHub Enterprise, vous pouvez également créer des ensembles de règles pour les dépôts d'une organisation. Pour plus d’informations, consultez « Création d'ensembles de règles pour les dépôts de votre organisation ».

Utilisation de la syntaxe fnmatch

Syntaxe fnmatch non prise en charge

Toutes les expressions de la syntaxe fnmatch ne sont pas prises en charge dans les règles de protection des branches. Tenez compte des contraintes suivantes :

  • Vous ne pouvez pas utiliser la barre oblique inverse (\) comme caractère de citation, car GitHub ne prend pas en charge l’utilisation de barres obliques inverses dans les règles de protection des branches.
  • Vous pouvez spécifier des jeux de caractères entre crochets ([]), mais actuellement, vous ne pouvez pas compléter un jeu avec l’opérateur ^ (par exemple, [^charset]).
  • Bien que GitHub prend en charge File::FNM_PATHNAME dans la syntaxe fnmatch, File::FNM_EXTGLOB n’est pas pris en charge.

Utilisation d’expressions régulières pour les métadonnées de commit

Lorsque vous ajoutez des restrictions de métadonnées pour un ensemble de règles ciblant des branches ou des balises, vous pouvez utiliser la syntaxe d’expression régulière pour définir des modèles auxquels les métadonnées pertinentes, telles que le message de commit ou le nom de la branche ou de l’étiquette, doivent ou ne doivent pas correspondre.

Par défaut, les restrictions de métadonnées n'acceptent pas les modèles d'expression régulière. Pour l’activer, sélectionnez la restriction Doit correspondre à un modèle d’expression régulière donné lorsque vous créez les restrictions de métadonnées pour votre ensemble de règles.

Les ensembles de règles prennent en charge la syntaxe RE2. Pour plus d’informations, consultez le Guide de la syntaxe de Google. Pour valider vos expressions, vous pouvez utiliser le validateur sur regex101.com en sélectionnant la saveur « Golang » dans la barre latérale gauche.

Par défaut, les expressions régulières dans les restrictions de métadonnées ne prennent pas en compte plusieurs lignes de texte. Par exemple, si vous avez un message de validation multiligne, le modèle ^ABC est une correspondance si une ligne du message commence par ABC. Pour correspondre à plusieurs lignes du message, commencez votre expression par (?m).

L’assertion avant négative, représentée par ?!, n’est pas prise en charge. Toutefois, dans les cas où vous devez rechercher une chaîne donnée qui n’est pas suivie d’une autre chaîne donnée, vous pouvez utiliser l’assertion avant positive, représentée par ?, combinée à la condition « Ne doit pas correspondre à un modèle regex donné ».

Remarque

Si vous exigez que les contributeurs valident les commits, cela peut interférer avec vos modèles d’expression régulière. Quand une personne procède à une validation, GitHub ajoute une chaîne comme Signed-off-by: #AUTHOR-NAME <#AUTHOR-EMAIL> au message de commit. Pour plus d’informations, consultez « Gestion de la stratégie de validation de commits pour votre organisation ».

Modèles d’expressions régulières utiles

Les exemples suivants fournissent des modèles utiles pour les métadonnées de commit. Pour utiliser ces modèles, définissez Condition requise sur « Doit correspondre à un modèle d’expression régulière donné ».

Vérifier que les noms de branche sont compatibles avec Windows

Vous pouvez utiliser le modèle suivant pour vous assurer que les noms de branche comprennent uniquement des nombres, des lettres minuscules et les caractères - et _. Cela garantit que les noms de branche sont compatibles avec les systèmes d’exploitation qui n’utilisent pas de systèmes de fichiers sensibles à la casse par défaut.

Text
\A[0-9a-z-_]$

Correspond à : my-branch

Ne correspond pas à : myBranch

Vérifier que les noms d’étiquette utilisent une gestion de versions sémantique

Vous pouvez utiliser le modèle suivant pour vous assurer que les noms d’étiquette sont conformes à une gestion de versions sémantique. Pour plus d’informations, consultez la documentation sur semver.org.

Text
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

Correspond à : 1.2.3, 10.20.30, 1.1.2-prerelease+meta

Ne correspond pas à : 1.2, 1.2-SNAPSHOT

Limiter la longueur des lignes dans les messages de commit

Le livre Pro Git recommande de limiter la première ligne d’un message de commit à environ 50 caractères.

Vous pouvez utiliser le modèle suivant pour vous assurer que la première ligne d’un message de commit contient 50 caractères ou moins.

Text
\A.{1,50}$
Vérifier que les messages de commit commencent par une résolution et un numéro de problème

Vous pouvez utiliser le modèle suivant pour vous assurer que les messages de commit contiennent le mot Resolves: ou Fixes:, suivi d’une chaîne telle que #1234.

Text
^(Resolves|Fixes): \#[0-9]+$

Correspond à : Fixes: #1234

Ne correspond pas à : Add conditional logic to foo.bar

Appliquer des commits conventionnels

Vous pouvez utiliser le modèle suivant pour vous assurer que les messages de commit sont conformes à la spécification relative aux commits conventionnels. Pour plus d’informations, consultez conventionalcommits.org.

Text
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)

Correspond à : feat: allow provided config object to extend other configs

Ne correspond pas à : Add conditional logic to foo.bar

Utilisation des états d'application d'ensembles de règles

Lors de la création ou de la modification de votre ensemble de règles, vous pouvez utiliser les statuts de mise en œuvre pour configurer la manière dont votre ensemble de règles mettra en œuvre les principes de protection des informations personnelles.

Vous pouvez sélectionner l'un des états de mise œuvre suivants pour votre ensemble de règles.

  •      **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-play" aria-label="play" role="img"><path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm4.879-2.773 4.264 2.559a.25.25 0 0 1 0 .428l-4.264 2.559A.25.25 0 0 1 6 10.559V5.442a.25.25 0 0 1 .379-.215Z"></path></svg> Actif **: votre ensemble de règles sera appliqué lors de la création.

  •      **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-meter" aria-label="meter" role="img"><path d="M8 1.5a6.5 6.5 0 1 0 6.016 4.035.75.75 0 0 1 1.388-.57 8 8 0 1 1-4.37-4.37.75.75 0 1 1-.569 1.389A6.473 6.473 0 0 0 8 1.5Zm6.28.22a.75.75 0 0 1 0 1.06l-4.063 4.064a2.5 2.5 0 1 1-1.06-1.06L13.22 1.72a.75.75 0 0 1 1.06 0ZM7 8a1 1 0 1 0 2 0 1 1 0 0 0-2 0Z"></path></svg> Évaluer **: votre ensemble de règles ne sera pas appliqué, mais vous serez en mesure de surveiller les actions qui violent ou non les règles sur la page « Aperçus des règles ».

  •      **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-skip" aria-label="skip" role="img"><path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm9.78-2.22-5.5 5.5a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734l5.5-5.5a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path></svg> Désactivé **: votre ensemble de règles ne sera pas appliqué ou évalué.

L’utilisation du mode « Évaluer » est une excellente option pour tester votre ensemble de règles sans l’appliquer. Vous pouvez utiliser la page « Aperçu des règles » pour voir si l’action aurait violé la règle.

Création d'un ensemble de règles de branche ou de balise

Octroi d'autorisations de contournement pour votre ensemble de règles de branche ou de balise

Choix des branches ou des balises à cibler

Pour cibler les branches ou les balises, dans la section « Cibler des branches » ou « Cibler des balises », sélectionnez Ajouter une cible, puis sélectionnez la façon dont vous souhaitez inclure ou exclure des branches ou des étiquettes. Vous pouvez utiliser la syntaxe fnmatch pour inclure ou exclure des branches ou des étiquettes sur la base d’un modèle. Pour plus d’informations, consultez Utilisation fnmatch de la syntaxe.

Vous pouvez ajouter plusieurs critères de ciblage au même ensemble de règles. Par exemple, vous pouvez inclure la branche par défaut, inclure toutes les branches correspondant au modèle *feature*, puis exclure spécifiquement une branche correspondant au modèle not-a-feature.

Sélection de protections de branche ou de balise

Dans la section « Protections de branches » ou « Protections d’étiquettes », sélectionnez les règles que vous souhaitez inclure dans l’ensemble de règles. Lorsque vous sélectionnez une règle, vous pouvez entrer des paramètres supplémentaires pour la règle. Pour plus d’informations sur les règles, consultez Règles disponibles pour les ensembles de règles.

Remarque

Si vous sélectionnez Exiger des contrôles d'état avant la fusion , dans la section « Paramètres supplémentaires » :

  • Vous pouvez entrer le nom de chaque vérification d’état que vous souhaitez exiger. Pour terminer l’ajout de la vérification d’état comme condition requise, vous devez cliquer sur .
  • Si vous sélectionnez Exiger que les branches soient à jour avant la fusion, vous devez définir une vérification pour que la protection prenne effet.

Ajout de restrictions des métadonnées

Vos restrictions en matière de métadonnées doivent avoir pour but d'améliorer la cohérence entre les modifications apportées à votre référentiel. Elles ne sont pas destinées à remplacer les mesures de sécurité, comme exiger une révision du code via des demandes de tirage.

Remarque

Si vous effectuez la fusion Squash d’une branche, toutes les validations sur cette branche doivent répondre à toutes les exigences de métadonnées pour la branche de base.

Lorsque vous utilisez des ancres de fin de ligne dans des expressions régulières, utilisez \n?$ plutôt que $ seul. Le paramètre facultatif \n? correspond à un saut de ligne final qui peut être présent dans les opérations Push/CLI de Git, tout en étant compatible avec les validations créées via l’interface utilisateur Web et l’API.

  1. Pour ajouter une règle permettant de contrôler les métadonnées de validation ou les noms de branche, dans la section « Restrictions » lors de la création ou de la modification d'un jeu de règles, cliquez sur Restreindre les métadonnées de validation ou sur Restreindre les noms de branche.

  2. Configurez les paramètres de restriction, puis cliquez sur Ajouter. Vous pouvez ajouter plusieurs restrictions au même ensemble de règles.

  3. Pour correspondre à un modèle d’expression régulière donné, dans la liste déroulante « Condition requise », sélectionnez Doit correspondre à un modèle d’expression régulière donné.

    Pour la plupart des conditions, telles que « Doit commencer par un modèle de correspondance », le modèle que vous entrez est interprété littéralement et les caractères génériques ne sont pas pris en charge. Par exemple, le caractère * représente uniquement le caractère * littéral.

    Pour les modèles plus complexes, vous pouvez sélectionner « Doit correspondre à un modèle regex donné » ou « Ne doit pas correspondre à un modèle regex donné », puis utiliser la syntaxe d’expression régulière pour définir le modèle correspondant. Pour plus d’informations, consultez À propos des expressions régulières pour les métadonnées de livraison" in the GitHub Enterprise Cloud documentation.

    Toute personne visualisant les ensembles de règles d’un dépôt peut voir la description que vous fournissez.

  4. Si vous le souhaitez, avant d'appliquer votre jeu de règles avec des restrictions sur les métadonnées, sélectionnez l'état d'application « Évaluer » pour votre jeu de règles afin de tester les effets des restrictions sur les métadonnées sans impacter les contributeurs. Pour plus d’informations sur les restrictions de métadonnées, consultez Règles disponibles pour les ensembles de règles.

Finalisation de l'ensemble de règles de votre branche ou de votre balise et étapes suivantes

Pour terminer la création de votre ensemble de règles, cliquez sur Créer. Si le statut de l’application de l’ensemble de règles est défini sur « Actif », l’ensemble de règles prend effet immédiatement.

Vous pouvez afficher des aperçus pour l’ensemble de règles pour voir comment les règles affectent vos collaborateurs. Si le statut de l’application est défini sur « Évaluer », vous pouvez voir quelles actions auraient réussi ou échoué si l’ensemble de règles était actif. Pour plus d’informations sur les aperçus des ensemble de règles, voir Gestion des ensembles de règles d’un dépôt.

Création d'un ensemble de règles de push

Remarque

Cet ensemble de règles appliquera les restrictions d’envoi (push) pour l’ensemble du réseau de duplications (fork) d’un référentiel.

Vous pouvez créer un ensemble de règles de push à partir de dépôts publics, privés ou internes.

Octroi d'autorisations de contournement pour votre ensemble de règles de push

Remarque

Les autorisations de contournement pour les ensembles de règles de push de ce dépôt seront héritées par l'ensemble du réseau de duplications pour ce dépôt. 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.

Vous pouvez accorder à certains rôles, équipes ou applications des autorisations de contournement ainsi que la possibilité d'approuver les demandes de contournement pour votre ensemble de règles. Voici ce qui peut contourner l'accès :

  • administrateurs de dépôts, propriétaires d’organisation et propriétaires d’entreprise
  • Le rôle de maintenance ou d’écriture, ou les rôles de dépôt personnalisés en fonction du rôle d’écriture
  • Les équipes, à l’exclusion des équipes secrètes. Voir À propos des équipes d'organisation.
  • Les clés de déploiement
  • GitHub Apps
  • Dependabot. Pour plus d’informations sur Dependabot, consultez Guide de démarrage rapide Dependabot.
  1. Pour accorder des autorisations de contournement pour l’ensemble de règles, dans la section « Liste de contournement », cliquez sur Add bypass.
  2. Dans la boîte de dialogue modale « Ajouter un contournement » qui s’affiche, recherchez le rôle, l’équipe ou l’application à laquelle vous souhaitez accorder des autorisations de contournement, puis sélectionnez le rôle, l’équipe ou l’application dans la section « Suggestions » et cliquez sur Ajouter la sélection.

Sélection de protections de push

Vous pouvez bloquer les poussées vers ce référentiel 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.

Toutes les protections de poussées que vous configurez bloquent les poussées dans ce référentiel et dans l’ensemble du réseau de fourche de ce référentiel.

  1. Sous « Protections des poussées », cliquez sur les restrictions que vous souhaitez appliquer. Renseignez ensuite les détails des restrictions que vous sélectionnez.

    Pour les restrictions de chemin d’accès de fichier, vous pouvez utiliser des chemins partiels ou complets. 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 ».

Finalisation de votre ensemble de règles de push et étapes suivantes

Pour terminer la création de votre ensemble de règles, cliquez sur Créer. Si le statut de l’application de l’ensemble de règles est défini sur « Actif », l’ensemble de règles prend effet immédiatement.

Vous pouvez afficher des aperçus pour l’ensemble de règles pour voir comment les règles affectent vos collaborateurs. Si le statut de l’application est défini sur « Évaluer », vous pouvez voir quelles actions auraient réussi ou échoué si l’ensemble de règles était actif. Pour plus d’informations sur les aperçus des ensemble de règles, voir Gestion des ensembles de règles d’un dépôt.