About rulesets

About rulesets

A ruleset is a named list of rules that applies to a repository, or to multiple repositories in an organization. You can have up to 75 rulesets per repository, and 75 organization-wide rulesets.

When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with a certain role, such as repository administrator, or it can be specific teams or GitHub Apps. For more information about granting bypass permissions, see Создание наборов правил для репозитория.

For organizations on the GitHub Enterprise plan, you can set up rulesets at the enterprise or organization level to target multiple repositories in your organization. See Управление наборами правил для репозиториев в организации.

You can use rulesets to target branches or tags in a repository or to block pushes to a repository and the repository's entire fork network.

Делегированный обход для наборов правил push-уведомлений позволяет управлять тем, кто может обойти защиту от push-уведомлений и которые должны быть разрешены заблокированными push-отправками.

При делегированном обходе участники репозитория должны запрашивать "обход привилегий" при отправке фиксаций, содержащих ограниченное содержимое. Запрос отправляется в назначенную группу рецензентов, которые либо утверждают, либо запрещают запрос об обходе правил отправки.

Если запрос на обход правил принудительной отправки утвержден, участник может отправить фиксацию, содержащую ограниченное содержимое. Если запрос отклонен, участник должен удалить содержимое из фиксации (или фиксации), содержащее ограниченное содержимое, прежде чем повторно отправить его.

Чтобы настроить делегированный обход, владелец организации или администраторы репозитория сначала создадут список обхода. Список обходов включает определенные роли и команды, такие как администраторы команды или репозитория, которые контролируют запросы на обход принудительной защиты. Дополнительные сведения см. в разделе [AUTOTITLE и Управление наборами правил для репозиториев в организации](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets).

Branch and tag rulesets

You can create rulesets to control how people can interact with selected branches and tags in a repository. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. For example, you could set up a ruleset for your repository's feature branch that requires signed commits and blocks force pushes for all users except repository administrators.

For each ruleset you create, you specify which branches or tags in your repository, or which repositories in your organization, the ruleset applies to. You can use fnmatch syntax to define a pattern to target specific branches, tags, and repositories. For example, you could use the pattern releases/**/* to target all branches in your repository whose name starts with the string releases/. For more information on fnmatch syntax, see Создание наборов правил для репозитория.

Push rulesets

С помощью наборов правил push-уведомлений можно блокировать отправки в частный или внутренний репозиторий и всю сеть вилки репозитория на основе расширений файлов, длины пути к файлам, пути к файлам и папкам, а также размеров файлов.

Правила принудительной отправки не требуют ветвей, так как они применяются к каждому принудительному отправке в репозиторий.

Push-наборы правил позволяют выполнять следующие действия.

• Ограничить пути к файлам: запретить фиксации, включающие изменения в указанные пути к файлам.

  Для этого можно использовать fnmatch синтаксис. Например, ограничение, предназначенное для test/demo/**/* предотвращения отправки в файлы или папки в test/demo/ каталоге. Ограничение, предназначенное для test/docs/pushrules.md предотвращения отправки pushrules.md в файл в каталоге test/docs/ . Дополнительные сведения см. в разделе Создание наборов правил для репозитория.

• Ограничить длину пути к файлу: запретить фиксации, включающие пути к файлам, превышающие указанное ограничение символов от отправки.

• Ограничение расширений файлов. Запретить отправку фиксаций, включающих файлы с указанными расширениями файлов.

• Ограничение размера файла. Запретить отправку фиксаций, превышающих указанное ограничение размера файла.

Сведения о наборе правил push для вилированных репозиториев

Правила отправки применяются ко всей сети вилки для репозитория, обеспечивая защиту каждой точки входа в репозиторий. Например, если вы вилку репозитория с включенными наборами правил push-уведомлений, то те же наборы правил push-уведомлений также будут применяться к вашему вилку репозитория.

Для вилированного репозитория единственными пользователями, у которых есть разрешения обхода для правила принудительной отправки, являются пользователи, у которых есть разрешения обхода в корневом репозитории.

About rulesets and protected branches

Rulesets work alongside any branch protection rules in a repository. Many of the rules you can define in rulesets are similar to protection rules, and you can start using rulesets without overriding any of your existing protection rules.

Rulesets have the following advantages over branch protection rules.

• Unlike protection rules, multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch in your repository will be evaluated when someone interacts with that branch. See About rule layering.
• Rulesets have statuses, so you can easily manage which rulesets are active in a repository without needing to delete rulesets.
• Anyone with read access to a repository can view the active rulesets for the repository. This means a developer can understand why they have hit a rule, or an auditor can check the security constraints for the repository, without requiring admin access to the repository.
• You can create additional rules to control the metadata of commits entering a repository, such as the commit message and the author's email address. See Доступные правила для наборов правил."

Using ruleset enforcement statuses

При создании или изменении набора правил можно использовать состояния принудительного применения, чтобы настроить применение набора правил.

Для набора правил можно выбрать любое из следующих состояний принудительного применения.

• Активный: набор правил будет применяться при создании.{ % ifversion repo-rules-enterprise %}
• Оцените: набор правил не будет применяться, но вы сможете отслеживать, какие действия будут или не нарушать правила на странице "Аналитика правил". { % endif %}
• Отключен: набор правил не будет применяться или вычисляется.

Использование режима "Оценка" — отличный вариант для тестирования набора правил, не применяя его. Вы можете использовать страницу "Аналитика правил", чтобы узнать, нарушил ли вклад правило. Дополнительные сведения см. в разделе Управление наборами правил для репозитория.

About rule layering

A ruleset does not have a priority. Instead, if multiple rulesets target the same branch or tag in a repository, the rules in each of these rulesets are aggregated. If the same rule is defined in different ways across the aggregated rulesets, the most restrictive version of the rule applies. As well as layering with each other, rulesets also layer with protection rules targeting the same branch or tag.

For example, consider the following situation for the my-feature branch of the octo-org/octo-repo repository.

• An administrator of the repository has set up a ruleset targeting the my-feature branch. This ruleset requires signed commits, and three reviews on pull requests before they can be merged.
• An existing branch protection rule for the my-feature branch requires a linear commit history, and two reviews on pull requests before they can be merged.
• An administrator of the octo-org organization has also set up a ruleset targeting the my-feature branch of the octo-repo repository. The ruleset blocks force pushes, and requires one review on pull requests before they can be merged.

The rules from each source are aggregated, and all rules apply. Where multiple different versions of the same rule exist, the result is that the most restrictive version of the rule applies. Therefore, the my-feature branch requires signed commits and a linear commit history, force pushes are blocked, and pull requests targeting the branch will require three reviews before they can be merged.

Next steps

Next, learn how to communicate important information with members of your enterprise using READMEs. See Create a README for your enterprise.