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

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

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

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

Для организаций в планах GitHub Enterprise и GitHub Team можно настроить наборы правил на уровне организации для целевых нескольких репозиториев в организации. Дополнительные сведения см. в разделе "Управление наборами правил для репозиториев в организации".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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