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

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

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

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

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

Существует ограничение в 75 наборов правил для каждого репозитория, а также 75 наборов правил для всей организации.

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

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

Кроме того, можно импортировать существующие правила защиты тегов в наборы правил репозитория. В настоящее время для репозитория будут реализованы те же защиты тегов. Дополнительные сведения см. в разделе "Настройка правил защиты тегов".

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

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

Кроме того, для организаций в плане GitHub Enterprise можно выполнить следующие действия с помощью наборов правил.

• Быстро настройте наборы правил на уровне организации для целевых нескольких репозиториев в организации. Дополнительные сведения см. в разделе "Управление наборами правил для репозиториев в организации".
• Создайте дополнительные правила для управления метаданными фиксаций, входящих в репозиторий, таких как сообщение фиксации и адрес электронной почты автора. Дополнительные сведения см. в разделе "Доступные правила для наборов правил".
• Используйте состояние "Оценка", чтобы протестировать набор правил перед его активным и использовать страницу аналитики для просмотра действий пользователей, затронутых правилами. Дополнительные сведения см. в разделе "Управление наборами правил для репозитория".

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

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

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

• Администратор репозитория настроил набор правил, my-feature предназначенный для ветви. Для этого набора правил требуются подписанные фиксации и три проверки на запросы на вытягивание, прежде чем их можно объединить.
• Для существующего правила my-feature защиты ветви требуется журнал линейной фиксации и два проверки запросов на вытягивание, прежде чем они могут быть объединены.{ % ifversion repo-rules-enterprise %}
• Администратор octo-org организации также настроил набор правил, my-feature предназначенный для ветви octo-repo репозитория. Набор правил блокирует принудительная отправка и требует проверки запросов на вытягивание, прежде чем их можно объединить.{ % endif %}

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