À 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, ou à plusieurs dépôts d’une organisation. Vous pouvez avoir jusqu’à 75 ensembles de règles par référentiel, et 75 ensembles de règles à l'échelle de l'organisation.

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.

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, la façon dont les commits doivent être mis en forme, 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, ou les dépôts de votre organisation, auxquels l’ensemble de règles s’applique. Vous pouvez utiliser la syntaxe fnmatch pour définir un modèle visant à cibler des branches, étiquettes et dépôts. 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.

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

Les ensembles de règles fonctionnent avec toutes les règles de protection 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.

En outre, vous pouvez importer des règles de protection des balises existantes dans des ensembles de règles de référentiel. Cette action implémente les mêmes protections de balise que celles que vous avez actuellement pour votre référentiel. Consultez Configuration de règles de protection d’étiquettes.

Les ensembles de règles présentent les avantages suivants par rapport aux branches et aux règles de 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 ou une étiquette de votre dépôt est évaluée quand une personne interagit avec cette branche ou cette étiquette. 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.
• ** É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 ».

À 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.
• Un administrateur de l’organisation octo-org a également configuré un ensemble de règles ciblant la branche my-feature du dépôt octo-repo. L’ensemble de règles bloque les poussées forcées et exige une révision sur les demandes de tirage avant qu’elles 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, les poussées forcées sont bloquées, et les demandes de tirage ciblant la branche exigent trois révisions avant de pouvoir être fusionnées.