Enforcing code governance in your enterprise with rulesets

Introduction

You can create rulesets to control how users can interact with code in repositories across your enterprise. You can:

• Create a branch or tag ruleset to control things like who can push commits to a certain branch, how commits must be formatted, or who can delete or rename a tag.
• Create a push ruleset to block pushes to a private or internal repository and the repository's entire fork network. Push rulesets allow you to block pushes based on file extensions, file path lengths, file and folder paths, and file sizes.

To learn more, see À propos des ensembles de règles.

Importing prebuilt rulesets

To import a prebuilt ruleset created by GitHub, see github/ruleset-recipes.

Vous pouvez importer un ensemble de règles à partir d’un autre référentiel ou d’une autre organisation à l’aide d’un fichier JSON. Ceci peut être utile si vous souhaitez appliquer le même ensemble de règles à plusieurs référentiels ou organisations. For more information, see "Gestion des ensembles de règles pour les dépôts de votre organisation."

How will I define where my ruleset applies?

Rulesets allow you to flexibly target the organizations, repositories, and branches where you want rules to apply.

• To target organizations, you can select all, choose from a list, or define a dynamic pattern for organization names using fnmatch syntax. For syntax details, see Création d’un ensemble de règles pour un dépôt.
• Within those organizations, you can target all repositories, or target a dynamic list by custom property. See Gestion des propriétés personnalisées pour les référentiels de votre organisation.
• Within the repositories, you can target certain branches or tags: all branches, the default branch, or a dynamic list using fnmatch syntax.

When you create a ruleset that targets branches in a repository, repository administrators can no longer rename branches or change the default branch in the targeted repository. They can still create and delete branches if they have the appropriate permissions.

How can I control the format of commits?

In branch or tag rulesets, you can add a rule that restricts the format of commit metadata such as commit message or author email.

If you select Must match a given regex pattern restriction, you can use regular expression syntax to define patterns that the metadata must or must not match. For syntax details and examples, see Création d’un ensemble de règles pour un dépôt.

Using ruleset enforcement statuses

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.

• ** Actif **: votre ensemble de règles sera appliqué lors de la création.
• ** É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 ».
• ** Désactivé **: votre ensemble de règles n’est pas appliqué or evaluated.

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. Pour plus d’informations, consultez « Gestion des ensembles de règles d’un dépôt ».

Creating a branch or tag ruleset

1. Dans le coin supérieur droit de GitHub, cliquez sur votre photo de profil.

2. En fonction de votre environnement, cliquez sur Votre entreprise ou sur Vos entreprises, puis cliquez sur l'entreprise que vous souhaitez consulter.

3. Sur le côté gauche de la page, dans la barre latérale du compte d’entreprise, cliquez sur Stratégies.

4. Under "Policies", click Code.

5. Cliquez sur Nouveau jeu de données.

6. Pour créer un ensemble de règles ciblant des branches, cliquez sur Nouvel ensemble de règles de branche.

7. Vous pouvez également créer un ensemble de règles ciblant des balises, cliquez sur Nouvel ensemble de règles de balise.

8. Sous « Nom de l’ensemble de règles », tapez un nom pour l’ensemble de règles.

9. Si vous le souhaitez, pour modifier l’état d’application par défaut, cliquez sur Désactivé et sélectionnez un état d’application. Pour plus d’informations sur les états de mise en œuvre, consultez À propos des ensembles de règles.

Granting bypass permissions for your branch or tag ruleset

You can grant certain roles, teams, or apps bypass permissions as well as the ability to approve bypass requests for your ruleset.

The following are eligible for bypass access:

• Repository admins, organization owners, and enterprise owners
• The maintain or write role, or deploy keys.

1. To grant bypass permissions for the ruleset, in the "Bypass list" section, click Add bypass.

2. In the "Add bypass" modal dialog that appears, search for the role, team, or app you would like to grant bypass permissions, then select the role, team, or app from the "Suggestions" section and click Add Selected.

3. Si vous le souhaitez, pour accorder un contournement à un acteur sans lui permettre de pousser directement vers un référentiel, à droite de « Toujours autoriser », cliquez sur , puis cliquez sur Pour les demandes de tirage uniquement.

   L’acteur sélectionné est maintenant tenu d’ouvrir une demande de tirage pour apporter des modifications à un référentiel, en créant une trace claire de ses modifications dans la demande de tirage et le journal d'audit. L’acteur peut ensuite choisir de contourner les protections de branche et de fusionner cette demande de tirage.

Choosing which organizations to target in your enterprise

Select all organizations, choose a selection of existing organizations, or set a dynamic list by name. If you use Enterprise Managed Users, you can also choose to target all repositories owned by users in your enterprise.

If you set a dynamic list, you'll add one or more naming patterns using fnmatch syntax. For example, the string *open-source would match any organization with a name that ends with open-source. For syntax details, see "Création d’un ensemble de règles pour un dépôt."

Choosing which repositories to target in your enterprise

Within the selected organizations, you can target all repositories or target a dynamic list by custom property. See Gestion des propriétés personnalisées pour les référentiels de votre organisation.

Choosing which branches or tags to target

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.

Selecting branch or tag protections

In the "Branch protections" or "Tag protections" section, select the rules you want to include in the ruleset. When you select a rule, you may be able to enter additional settings for the rule. For more information on the rules, see "Règles disponibles pour les ensembles de règles"

Adding metadata restrictions

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.

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.

   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.

Finalizing your branch or tag ruleset and next steps

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.

Creating a push ruleset

You can create a push ruleset for private or internal repositories in your enterprise.

1. Dans le coin supérieur droit de GitHub, cliquez sur votre photo de profil.
2. En fonction de votre environnement, cliquez sur Votre entreprise ou sur Vos entreprises, puis cliquez sur l'entreprise que vous souhaitez consulter.
3. In the left sidebar, in the "Policies" section, click Code.
4. Click New ruleset.
5. Click New push ruleset.
6. Under "Ruleset name," type a name for the ruleset.
7. Optionally, to change the default enforcement status, click Disabled and select an enforcement status. For more information about enforcement statuses, see À propos des ensembles de règles

Granting bypass permissions for your push ruleset

You can grant certain roles, teams, or apps bypass permissions as well as the ability to approve bypass requests for your ruleset. The following are eligible for bypass access:

• Repository admins, organization owners, and enterprise owners
• The maintain or write role, or deploy keys

1. To grant bypass permissions for the ruleset, in the "Bypass list" section, click Add bypass.
2. In the "Add bypass" modal dialog that appears, search for the role, team, or app you would like to grant bypass permissions, then select the role, team, or app from the "Suggestions" section and click Add Selected.

Choosing which organizations to target in your enterprise

Select all organizations, choose a selection of existing organizations, or set a dynamic list by name. If you use Enterprise Managed Users, you can also choose to target all repositories owned by users in your enterprise.

If you set a dynamic list, you'll add one or more naming patterns using fnmatch syntax. For example, the string *open-source would match any organization with a name that ends with open-source. For syntax details, see "Création d’un ensemble de règles pour un dépôt."

Choosing which repositories to target in your enterprise

Within your chosen organizations, you can target all repositories, or target a dynamic list using custom properties. See Gestion des propriétés personnalisées pour les référentiels de votre organisation.

Selecting push protections

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’un ensemble de règles pour un dépôt ».

Finalizing your push ruleset and next steps

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.