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

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

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

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

Для организаций, находящихся в плане GitHub Enterprise , вы можете настроить наборы правил на организации, чтобы таргетировать несколько репозиториев в вашей организации. См. Управление наборами правил для репозиториев в организации в GitHub Enterprise Cloud документации.

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

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

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

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