Сведения о наборе правил
Набор правил — это именованный список правил, которые применяются к репозиторию, или к нескольким репозиториям в организации. Вы можете создавать наборы правил для управления тем, как люди могут взаимодействовать с выбранными ветвями и тегами в репозитории. Вы можете управлять тем, кто может отправлять фиксации в определенную ветвь и как фиксации должны быть отформатированы, или кто может удалить или переименовать тег. Например, можно настроить набор правил для ветви репозитория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
ветви требуются подписанные фиксации и журнал линейной фиксации, принудительная отправка блокируются, а запросы на вытягивание, предназначенные для ветви, потребуют трех проверок, прежде чем их можно объединить.