À propos des ensembles de règles

À propos des ensembles de règles

Un ensemble de règles est une liste nommée de règles qui s’applique à un dépôt. Vous pouvez avoir jusqu’à 75 ensembles de règles par 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 d’un certain rôle, comme administrateur de dépôt, d’équipes spécifiques ou d’GitHub Apps. Pour plus d’informations sur les autorisations de contournement, consultez Création d’un ensemble de règles pour un dépôt.

Pour les organisations sur le plan GitHub Enterprise, vous pouvez configurer des ensembles de règles au niveau de l’entreprise de l’organisation pour cibler plusieurs référentiels dans votre organisation. Consultez Gestion des ensembles de règles pour les dépôts de votre organisation dans la documentation GitHub Enterprise Cloud .

Vous pouvez utiliser des ensembles de règles pour cibler des branches ou des balises dans un référentiel ou bloquer les envois (push) vers un référentiel et l’ensemble du réseau de fourche du référentiel.

Ensembles de règles de branche et de balise

Vous pouvez créer des ensembles de règles pour contrôler la façon dont les personnes 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, ou qui peut supprimer ou renommer une étiquette. Par exemple, vous pouvez configurer un ensemble de règles pour la branche feature de votre dépôt qui exige des commits signés et bloque les poussées forcées de tous les utilisateurs, à l’exception des administrateurs de dépôt.

Pour chaque ensemble de règles que vous créez, vous spécifiez les branches ou étiquettes de votre dépôt auxquels l’ensemble de règles s’applique. Vous pouvez utiliser la syntaxe fnmatch pour définir un modèle visant à cibler des branches et étiquettes. Par exemple, vous pouvez utiliser le modèle releases/**/* pour cibler toutes les branches de votre dépôt dont le nom commence par la chaîne releases/. Pour plus d’informations sur la syntaxe fnmatch, consultez Création d’un ensemble de règles pour un dépôt.

Ensembles de règles de poussée

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.

À propos des ensembles de règles et des branches protégées

Les ensembles de règles et règles de protection dans un référentiel. La plupart des règles que vous pouvez définir dans les ensembles de règles sont similaires aux règles de protection, et vous pouvez commencer à utiliser des ensembles de règles sans remplacer l’une de vos règles de protection existantes.

Les ensembles de règles présentent les avantages suivants par rapport aux branches protection.

• Contrairement aux règles de protection, plusieurs ensembles de règles peuvent s’appliquer en même temps. Vous pouvez donc être sûr que chaque règle ciblant une branche de votre dépôt est évaluée quand une personne interagit avec cette branche. Consultez À propos de la superposition de règles.
• Les ensembles de règles ont des états, ce qui vous permet de gérer facilement les ensembles de règles actifs d’un dépôt sans avoir à en supprimer.
• Toute personne disposant d’un accès en lecture à un dépôt peut voir les ensembles de règles actifs du dépôt. Cela signifie qu’un développeur peut comprendre pourquoi il ne satisfait pas une règle, ou qu’un auditeur peut vérifier les contraintes de sécurité du dépôt, sans avoir besoin d’un accès administrateur au dépôt.
• Vous pouvez créer des règles supplémentaires pour contrôler les métadonnées des commits entrant dans un référentiel telles que le message de commit et l’adresse e-mail de l’auteur. Consultez Règles disponibles pour les ensembles de règles dans la documentation GitHub Enterprise Cloud.

Utilisation des états d’application de l’ensemble 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.

• ** Actif **: votre ensemble de règles sera appliqué lors de la création.
• ** Désactivé **: votre ensemble de règles n’est pas appliqué.

À propos de la superposition de règles

Un ensemble de règles n’a aucune priorité. Au lieu de cela, si plusieurs ensembles de règles ciblent la même branche ou la même étiquette dans un dépôt, les règles de chacun de ces ensembles de règles sont agrégées. Si la même règle est définie de différentes manières dans les ensembles de règles agrégés, la version la plus restrictive de la règle s’applique. En plus de pouvoir être superposés entre eux, les ensembles de règles peuvent aussi être superposés à des règles de protection ciblant la même branche ou la même étiquette.

Par exemple, examinez la situation suivante pour la branche my-feature du dépôt octo-org/octo-repo.

• Un administrateur du dépôt a configuré un ensemble de règles ciblant la branche my-feature. Cet ensemble de règles exige des commits signés et trois révisions sur les demandes de tirage avant qu’elles ne puissent être fusionnées.
• Une règle de protection de branche existante pour la branche my-feature exige un historique de commits linéaire et deux révisions sur les demandes de tirage avant que celles-ci ne puissent être fusionnées.

Les règles de chaque source sont agrégées et toutes les règles s’appliquent. Lorsqu’il existe plusieurs versions différentes de la même règle, la version la plus restrictive de la règle s’applique. Par conséquent, la branche my-feature exige des commits signés et un historique de commits linéaire, et les demandes de tirage ciblant la branche exigent trois révisions avant de pouvoir être fusionnées.