
Наборы правил GitHub: несколько политик сильнее одной защиты ветки

Для защиты веток GitHub создайте набор правил, укажите целевые ветки, требования к слиянию и тех, кому разрешён обход. Если на ветке уже действует классическая защита, новый набор добавит к ней свои ограничения: до включения проверьте, какие требования придётся выполнять одновременно.
Для одного репозитория с единой политикой классического правила часто достаточно. Наборы полезнее, когда к ветке применяются разные политики репозитория и организации или когда изменения нужно предварительно оценить. Начните с выбора подходящего механизма, затем настройте охват правил и перенесите старую защиту без промежутка, в котором ветка останется открытой.
Как выбрать механизм для репозитория и организации

Классическая защита решает обычные задачи: требует одобрений, успешных проверок состояния, линейной истории и, при необходимости, очереди слияния. Если у репозитория одна основная ветка и все требования удобно хранить в одном правиле, сохраняйте эту настройку. Сам перенос в набор правил не сделает проверку кода строже.
Наборы удобны, когда требования должны складываться. Например, организация может задать общую политику для своих репозиториев, а отдельный репозиторий — добавить требования к веткам выпуска. Возможность централизованной настройки зависит от тарифа; для выбора также важно, кому разрешено изменять политику организации и кто управляет правилами самого репозитория.
- Один репозиторий и одна политика для ветки: оставьте классическую защиту, если она уже задаёт все нужные условия.
- Несколько требований с разными областями действия: используйте наборы правил и заранее определите, какие из них попадут на одну ветку.
- Общая политика для репозиториев организации: задайте её централизованно, а местные исключения и дополнительные требования учитывайте в каждом репозитории отдельно.
Классическое правило остаётся значимым и после создания набора. Поэтому переход стоит планировать для конкретной ветки: выпишите её действующую защиту, наборы репозитория и применимые правила организации. Такой список сразу покажет, где новая настройка дополняет существующую, а где повторяет её.
Как создать набор для нужных веток
Инструкция GitHub по созданию набора описывает выбор целевых веток, защитных требований, состояния набора и списка обхода. В настройках репозитория откройте раздел наборов правил и создайте набор для веток. Права на такое изменение нужны администратору репозитория или обладателю соответствующей роли.
- Дайте набору имя по его назначению. Выберите состояние: активный набор применяется сразу, а доступный режим предварительной оценки регистрирует возможные нарушения без блокировки.
- Укажите целевые ветки. Для основной ветки удобен точный выбор; для веток выпуска задайте шаблон и проверьте совпадение с реальными именами.
- Добавьте требования к запросам на слияние и проверкам состояния. Если ветка должна быть обновлена перед слиянием, задайте обязательную проверку, иначе это дополнительное условие не начнёт действовать.
- Заполните список обхода только для ролей, команд или приложений, которым он необходим. Вариант обхода лишь через запрос на слияние сохраняет этот путь внесения изменений.
- Сохраните набор и посмотрите, какие ветки он охватил. При доступной предварительной оценке изучите зарегистрированные действия, прежде чем переводить набор в активное состояние.
Шаблон веток требует отдельного внимания: звёздочка в нём не захватывает косую черту. Поэтому шаблон для ветки сразу под каталогом может не охватить более глубоко вложенное имя. Если команда использует такие имена, проверьте их до активации политики.
Для защиты выбранных веток создавайте именно набор для веток. Правила, ограничивающие отправку изменений в репозиторий, действуют в другой области и могут распространяться на сеть его ответвлений. Подмена одного вида правил другим изменит круг затронутых действий.
Какие требования действуют вместе
Описание наложения правил GitHub устанавливает принцип: к ветке могут применяться несколько наборов и одно классическое правило защиты. Наборы не выстраиваются по приоритету; их условия складываются, а при разной строгости одного требования действует более жёсткий вариант.
Условный пример: классическое правило требует двух одобрений, а набор — трёх. Для слияния понадобятся три одобрения; отдельное требование подписывать коммиты также сохранится, даже если его нет в классическом правиле. В результате проверять нужно весь набор условий для целевой ветки, а не только настройки последней созданной политики.
Права обхода считайте отдельно от обычных требований. Участник, команда или приложение могут быть внесены в список одного набора, но на ту же ветку могут действовать и другие ограничения. Проверьте списки каждого применимого набора и настройки классической защиты, особенно если автоматическое приложение должно отправлять изменения или сливать запросы.
Как перенести действующую защиту

Порядок преобразования GitHub позволяет перенести классическое правило по отдельности, увидеть новое поведение и оставить прежнюю защиту на время проверки. Преобразование может создать несколько наборов. Если старое правило сохранено, активный новый набор действует вместе с ним.
- Откройте настройки веток репозитория, найдите правило защиты и выберите преобразование в набор. Просмотрите предлагаемые наборы и раздел с описанием нового поведения.
- Сохраните старое правило. Если доступен режим предварительной оценки, начните с него: новый набор будет учитывать действия без применения своих ограничений, а прежняя защита продолжит действовать.
- Сверьте охват веток, обязательные проверки, одобрения и обход. Отдельно проверьте требование разрешить все обсуждения до слияния: при преобразовании оно не переносится в точности, поскольку в наборе связано с правилом для запросов на слияние.
- Переведите набор в активное состояние и проверьте обычный запрос на слияние, а также предусмотренный путь обхода. После проверки удалите классическое правило, если новый набор полностью покрывает нужную политику.
При создании преобразованного набора активное состояние может быть выбрано по умолчанию. Поэтому до сохранения посмотрите на его состояние и не удаляйте прежнюю защиту одновременно с созданием. Пока оба механизма включены, неожиданная блокировка слияния обычно требует проверки их совместных условий: совпадения ветки с шаблонами, обязательных проверок, одобрений и разрешений на обход.
Читайте также:
Похожие статьи


Plugin4Shell обходит проверку плагинов — два из четырёх агентов без исправления

Преимущества использования резервного копирования GitHub

GitHub Copilot или Cursor: дешёвая подписка не решает выбор новичка

API-ключ попал в Git: удаления строки недостаточно

Портфолио на GitHub: рекрутеру нужны 3–5 проектов, а не зелёный график
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.