Сведения о наборе правил

Сведения о наборе правил

Набор правил — это именованный список правил, который применяется к репозиторию или к нескольким репозиториям в организации для клиентов GitHub Team и GitHub Enterprise планов. Для каждого репозитория можно использовать до 75 наборов правил и 75 наборов правил на уровне организации.

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

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

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

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

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

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

Наборы правил ветви и тегов

Вы можете создавать наборы правил для управления тем, как люди могут взаимодействовать с выбранными ветвями и тегами в репозитории. Вы можете управлять такими вещами, как кто может push commit в определённую ветку и как должны быть отформатированы коммиты, или кто может удалять или переименовывать тег. Например, можно настроить набор правил для ветви репозиторияfeature, требующей подписанных фиксаций и блоков принудительная отправка для всех пользователей, кроме администраторов репозитория.

Для каждого созданного вами набора правил вы указываете, к каким веткам или тегам в вашем репозитории, или к каким репозиториям в вашей организации , применяется этот набор. Вы можете использовать fnmatch синтаксис, чтобы определить паттерн для таргетирования определённых ветвей, тегов и репозиториев. Например, шаблон можно использовать releases/**/* для назначения всех ветвей в репозитории, имя которого начинается со строки releases/. Дополнительные сведения о синтаксисе см. в fnmatch разделе Создание наборов правил для репозитория.

Наборы правил push-уведомлений

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

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

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

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

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

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

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

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

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

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

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

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

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

Наборы правил имеют следующие преимущества по сравнению с правилами защиты ветви.

• В отличие от правил защиты, одновременно могут применяться несколько наборов правил, поэтому вы можете быть уверены, что каждое правило, направленное на ветку в вашем репозитории, будет оцениваться при взаимодействии с этой веткой. См. статью "Сведения о уровне правил".
• Наборы правил имеют состояния, поэтому вы можете легко управлять тем, какие наборы правил активны в репозитории без необходимости удалять наборы правил.
• Любой пользователь с доступом на чтение к репозиторию может просматривать активные наборы правил для репозитория. Это означает, что разработчик может понять, почему они попали в правило, или аудитор может проверить ограничения безопасности для репозитория, не требуя доступа администратора к репозиторию.
• Можно создать дополнительные правила для управления метаданными фиксаций, входящих в репозиторий, таких как сообщение фиксации и адрес электронной почты автора. См. Доступные правила для наборов правил в GitHub Enterprise Cloud документации.

Использование состояний применения набора правил

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

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

• Активный: набор правил будет применяться при создании.
• Оцените: набор правил не будет применяться, но вы сможете отслеживать, какие действия будут или не нарушать правила на странице "Аналитика правил".
• Отключен: набор правил не будет применяться или вычисляется.

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

Сведения о многоуровневом уровне правил

Набор правил не имеет приоритета. Вместо этого, если несколько наборов правил предназначены для одной ветви или тега в репозитории, правила в каждом из этих наборов правил агрегируются. Если одно правило определено различными способами в объединенных наборах правил, применяется самая ограничивающая версия правила. А также слои друг с другом, наборы правил также с помощью правил защиты, предназначенных для той же ветви или тега.

Например, рассмотрим следующую ситуацию для my-feature ветви octo-org/octo-repo репозитория.

• Администратор репозитория настроил набор правил, my-feature предназначенный для ветви. Для этого набора правил требуются подписанные фиксации и три проверки на запросы на вытягивание, прежде чем их можно объединить.
• Существующее правило my-feature защиты ветки для ветки требует линейной истории коммита и двух проверок pull request перед их объединением.
• Администратор octo-org организации также настроил набор правил, my-feature предназначенный для ветви octo-repo репозитория. Блоки правил принудительно отправляют push и требуют одного просмотра pull request, прежде чем их можно объединить.

Правила из каждого источника агрегируются и применяются все правила. В тех случаях, когда существуют несколько разных версий одного правила, результатом является то, что применяется самая ограничивающая версия правила. Поэтому my-feature ветка требует подписанных коммитов и линейной истории коммитов, форс-пушы блокируются, а pull-запросы, направленные на ветку, требуют трёх проверок перед слиянием.