Сведения о правилах защиты ветвей
Создав правило защиты ветви, вы можете применять определенные рабочие процессы или требования, прежде чем сотрудник может отправить изменения в ветвь в репозитории, включая объединение запроса на вытягивание в ветвь.
По умолчанию каждое правило защиты ветви отключает принудительные отправки в соответствующие ветви и предотвращает удаление соответствующих ветвей. При необходимости эти ограничения можно отключить и включить дополнительные параметры защиты ветви.
По умолчанию ограничения правила защиты ветви не применяются к пользователям с разрешениями администратора для репозитория или пользовательских ролей с разрешением "обход защиты ветви". При необходимости вы также можете применить ограничения к администраторам и ролям с разрешением "обход защиты ветви". Дополнительные сведения см. в разделе Управление пользовательскими ролями репозитория для организации.
Для определенной ветви, всех ветвей или любой ветви, которая соответствует шаблону имени, заданному с помощью синтаксиса fnmatch, можно создать правило защиты ветви в репозитории. Например, чтобы защитить все ветви, содержащие слово release, можно создать правило ветви для *release*. Дополнительные сведения о шаблонах имен ветвей см. в разделе Управление правилом защиты ветвей.
Вы можете настроить запрос на вытягивание для автоматического объединения при соблюдении всех требований к объединению. Дополнительные сведения см. в разделе Автоматическое слияние запроса на вытягивание.
Сведения о параметрах защиты ветвей
Для каждого правила защиты ветви можно включить или отключить приведенные ниже параметры.
- Требовать проверки запросов на вытягивание перед слиянием
- Требовать проверки состояния перед слиянием
- Требовать устранения разногласий перед слиянием
- Требовать подписанные фиксации
- Требовать линейный журнал
- Требовать очередь слияния
- Требовать успешного развертывания перед слиянием
- Блокировка ветви - Не разрешать обход указанных выше параметров
- Ограничить пользователей, которые могут выполнять отправку в соответствующие ветви
- Разрешить принудительные отправки
- Разрешить удаления
Дополнительные сведения о настройке защиты ветвей см. в разделе Управление правилом защиты ветвей.
Требовать проверки запросов на вытягивание перед слиянием
Администраторы репозитория или пользовательские роли с разрешением "изменение правил репозитория" могут требовать, чтобы все запросы на вытягивание получали определенное количество утверждающих проверок, прежде чем кто-то объединит запрос на вытягивание в защищенную ветвь. Вы можете требовать утверждения проверок от пользователей с разрешениями на запись в репозиторий или от назначенного владельца кода.
Если включить необходимые проверки, участники совместной работы могут отправлять изменения только в защищенную ветвь с помощью запроса на вытягивание, утвержденного требуемым количеством рецензентов с разрешениями на запись.
Если пользователь с разрешениями администратора выбирает параметр Требовать изменения в проверке, он должен утвердить запрос на вытягивание до его слияния. Если рецензент, требующий изменения для запроса на вытягивание, недоступен, любой пользователь с разрешениями на запись в репозиторий может отклонить блокирующую проверку.
Даже если все обязательные проверяющие одобрили запрос на вытягивание, участники совместной работы не могут выполнить слияние для запроса на вытягивание, если есть другие открытые запросы на вытягивание, имеющие главную ветвь, указывающую на ту же фиксацию с ожидающими или отклоненными проверками. Кто-то с разрешениями на запись сначала должен утвердить или закрыть блокировку проверки на другие запросы на вытягивание.
Если участник совместной работы пытается выполнить слияние запроса на вытягивание с ожидающими или отклоненными проверками в защищенную ветвь, он получит сообщение об ошибке.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.При необходимости при отправке фиксаций можно отклонять устаревшие утверждения запросов на вытягивание. Если кто-либо отправляет фиксацию, которая изменяет код на утвержденный запрос на вытягивание, утверждение будет отклонено, и запрос на вытягивание будет невозможно объединить. Это не относится к случаям, когда участник совместной работы отправляет фиксации, не изменяющие код, например, слияние базовой ветви в ветвь запроса на вытягивание. Сведения о базовой ветви см. в разделе Сведения о запросах на вытягивание.
При необходимости можно ограничить возможность отклонять проверки запросов на вытягивание определенными людьми или командами. Дополнительные сведения см. в разделе Отклонение проверки запроса на вытягивание.
При необходимости можно требовать проведение проверок от владельцев кода. В этом случае любой запрос на вытягивание, влияющий на код, должен быть утвержден этим владельцем кода, прежде чем запрос на вытягивание можно будет объединить в защищенную ветвь.
При необходимости можно требовать утверждения от кого-либо, кроме последнего, для отправки в ветвь, прежде чем можно будет объединить запрос на вытягивание. Это гарантирует, что несколько пользователей увидят запросы на вытягивание в конечном состоянии, прежде чем они будут объединены в защищенную ветвь. Если включить эту функцию, последнему пользователю, который отправляет свои изменения, потребуется утверждение независимо от требуемой защиты ветви утверждений. Пользователи, которые уже рассмотрели запрос на вытягивание, могут повторно принять его после последней отправки в соответствии с этим требованием.
Требовать проверки состояния перед слиянием
Обязательные проверки состояния обеспечивают выполнение всех необходимых тестов непрерывной интеграции перед тем, как соавторы смогут вносить изменения в защищенную ветвь. Обязательные проверки состояния могут быть проверками или состояниями. Дополнительные сведения см. в разделе Сведения о проверках состояния.
Прежде чем включить обязательные проверки состояния, необходимо настроить репозиторий для использования API состояния фиксации. Дополнительные сведения см. в разделе Сведения о состояниях фиксации в документации по REST API.
После включения необходимых проверок состояния все они должны быть выполнены, после чего участники совместной работы смогут объединять изменения в защищенную ветвь. После прохождения всех необходимых проверок состояния все фиксации должны быть либо отправлены в другую ветвь, а затем объединены, либо или отправлены непосредственно в защищенную ветвь.
Любой пользователь или интеграция с разрешениями на запись в репозиторий может задать состояние любой проверки состояния в репозитории, но в некоторых случаях может потребоваться только принять проверку состояния из определенного GitHub App. При добавлении обязательной проверки состояния можно выбрать приложение, которое недавно установило эту проверку в качестве ожидаемого источника обновлений состояния. Если состояние задано любым другим пользователем или интеграцией, слияние не будет разрешено. Если выбрать вариант "Любой источник", по-прежнему можно вручную проверять автора каждого состояния, указанного в поле слияния.
Вы можете настроить требуемые проверки состояния как "Нестрогие" или "Строгие". Выбранный тип требуемой проверки состояния определяет, должна ли ваша ветвь быть обновлена в соответствии с базовой ветвью перед слиянием.
| Тип требуемой проверки состояния | Параметр | Требования к слиянию | Рекомендации |
|---|---|---|---|
| Strict | Установлен флажок Требовать актуальность ветвей перед слиянием. | Перед слиянием ветвь должна быть обновлена в соответствии с базовой ветвью. | Это поведение по умолчанию для требуемых проверок состояния. Могут потребоваться дополнительные сборки, так как вам будет необходимо обновлять главную ветвь после того, как другие участники совместной работы объединят запросы на вытягивание в защищенную базовую ветвь. |
| Нестрогая | Флажок Требовать актуальность ветвей перед слиянием не установлен. | Перед слиянием ветвь не должна быть обновлена в соответствии с базовой ветвью. | У вас будет меньше требуемых сборок, так как вам не нужно будет обновлять главную ветвь после того, как другие участники совместной работы объединят запросы на вытягивание. При наличии изменений, несовместимых с главной ветвью, проверки состояния могут завершиться ошибкой после слияния ветви. |
| Отключено | Флажок Требовать прохождения проверок состояния перед слиянием не установлен. | Ветвь не имеет ограничений на слияние. | Если требуемые проверки состояния не включены, участники совместной работы могут объединить ветвь в любое время независимо от того, обновлена ли она в соответствии с базовой ветвью. Это повышает вероятность возникновения несовместимых изменений. |
Сведения об устранении неполадок см. в разделе Устранение неполадок с обязательными проверками состояния.
Требовать устранения разногласий перед слиянием
Требует, чтобы все комментарии к запросу на вытягивание были разрешены, прежде чем его можно будет объединить с защищенной ветвью. Это гарантирует, что перед слиянием все комментарии будут разрешены или подтверждены.
Требование подписания фиксаций
При включении обязательного подписывания фиксации в ветви участники совместной работы и боты могут отправлять в ветвь только подписанные и проверенные фиксации. Дополнительные сведения см. в разделе Сведения о проверке подписи фиксации.
Примечания.
- Если включен режим бдительности, указывающий, что фиксации всегда будут подписаны, все фиксации, которые GitHub идентифицирует как "Частично проверенные", разрешены в ветвях, требующих подписанных фиксаций. Дополнительные сведения о режиме бдительности см. в разделе Отображение состояний проверки для всех фиксаций.
- Если участник совместной работы отправляет неподписанную фиксацию в ветвь, требующую подписания фиксации, ему потребуется переместить изменения из одной ветви в другую, чтобы включить проверенную подпись, а затем принудительно отправить переписанную фиксацию в ветвь.
Вы всегда можете отправлять локальные фиксации в ветвь, если они подписаны и проверены. Вы можете также объединить подписанные и проверенные фиксации в ветвь с помощью запроса на вытягивание в GitHub. Однако вы не можете объединить запрос на вытягивание в ветвь на GitHub, если вы не являетесь автором запроса на вытягивание. Вы можете squash и объединить запросы на вытягивание локально. Дополнительные сведения см. в разделе Локальное получение для изменения запросов на вытягивание.
Дополнительные сведения о методах слияния см. в разделе Сведения о методах слияния в GitHub.
Требовать линейный журнал
Если применяется линейный журнал фиксаций, участники совместной работы не смогут отправлять фиксации слияния в ветвь. Это означает, что все запросы на вытягивание, объединенные в защищенную ветвь, должны использовать слияние со сжатием или слияние с перемещением из одной ветви в другую. Используя строго линейный журнал фиксаций, команды могут быстрее отменять изменения. Дополнительные сведения о методах слияния см. в разделе Сведения о слиянии запросов на вытягивание.
Прежде чем требовать линейный журнал фиксаций, репозиторий должен разрешить слияние со сжатием или слияние с перемещением из одной ветви в другую. Дополнительные сведения см. в разделе Настройка слияния запросов на вытягивание.
Требовать очередь слияния
Примечание: Функция очереди слияния запросов на вытягивание в настоящее время находится в общедоступной бета-версии и может быть изменена.
Очередь объединения может увеличить скорость объединения запросов на вытягивание в занятую целевую ветвь, гарантируя успешное прохождение всех необходимых проверок защиты ветви.
После того как запрос на вытягивание прошел все необходимые проверки защиты ветви, пользователь с доступом на запись в репозиторий может добавить этот запрос на вытягивание в очередь объединения.
Очередь объединения может использовать GitHub Actions. Дополнительные сведения см. в разделе Документация по GitHub Actions.
GitHub объединяет запрос на вытягивание в соответствии со стратегией объединения, настроенной в системе защиты ветви после прохождения всех необходимых проверок CI.
Требовать успешного развертывания перед слиянием
Вы можете потребовать успешного развертывания изменений в определенные среды, прежде чем можно будет выполнить слияние ветви. Например, это правило можно использовать для успешного развертывания изменений в промежуточную среду перед слиянием изменений в ветвь по умолчанию.
Блокировка ветви
Блокировка ветви гарантирует отсутствие фиксаций в ветви. По умолчанию вилку репозитория не поддерживает синхронизацию из вышестоящего репозитория. Вы можете включить параметр Разрешить синхронизацию вилок для извлечения изменений из вышестоящего репозитория, не позволяя вносить другие изменения в ветвь вилки.
Не разрешать обход указанных выше параметров
По умолчанию ограничения правила защиты ветви не применяются к пользователям с разрешениями администратора для репозитория или пользовательских ролей с разрешением "обход защиты ветви" в репозитории.
Вы также можете включить этот параметр для применения ограничений к администраторам и ролям с разрешением "обход защиты ветви". Дополнительные сведения см. в разделе Управление пользовательскими ролями репозитория для организации.
Ограничить пользователей, которые могут выполнять отправку в соответствующие ветви
Вы можете включить ограничения ветви в общедоступных репозиториях, принадлежащих организации GitHub Free, и во всех репозиториях, принадлежащих организации, с помощью GitHub Team или GitHub Enterprise Cloud.
При включении ограничений для ветвей выполнять отправку в защищенную ветвь могут только пользователи, команды или приложения, которым предоставлено соответствующее разрешение. Просматривать и изменять пользователей, команды или приложения с правами на отправку в защищенную ветвь можно в параметрах защищенной ветви. Если требуются проверки состояния, пользователям, командам и приложениям, имеющим разрешение на отправку в защищенную ветвь, по-прежнему будет запрещено выполнять слияние в ветвь при сбое требуемых проверок. Пользователям, командам и приложениям, имеющим разрешение на отправку в защищенную ветвь, по-прежнему потребуется создать запрос на вытягивание, если требуются запросы на вытягивание.
При необходимости можно применить те же ограничения к созданию ветвей, которые соответствуют правилу. Например, если вы создаете правило, которое позволяет выполнять отправки в ветви, содержащие слово release, только определенной команде, только члены этой команды смогут создать новую ветвь, содержащую слово release.
Вы можете предоставить права на отправку в защищенную ветвь или предоставить разрешение на создание соответствующей ветви только пользователям, командам или установленным GitHub Apps с доступом на запись в репозиторий. Люди и приложения с разрешениями администратора для репозитория всегда могут отправить в защищенную ветвь или создать соответствующую ветвь.
Разрешить принудительные отправки
По умолчанию GitHub блокирует принудительные отправки во все защищенные ветви. При включении принудительной отправки в защищенную ветвь можно выбрать одну из двух групп, которые поддерживают принудительную отправку:
- Разрешить всем, у кого есть по крайней мере разрешения на запись в репозиторий, включая администраторов, выполнять принудительную отправку в ветвь.
- Разрешить выполнять принудительную отправку в ветвь только определенным пользователям или командам.
Если кто-то выполняет принудительную отправку в ветвь, такая отправка может перезаписать фиксации, являющиеся основой работы других участников совместной работы. У людей могут возникнуть конфликты слияния или появиться поврежденные запросы на вытягивание.
Включение принудительных отправок не переопределит другие правила защиты ветвей. Например, если ветви требуется линейный журнал фиксаций, принудительно отправлять фиксации слияния в эту ветвь невозможно.
Разрешить удаления
По умолчанию удалить защищенную ветвь невозможно. Если включено удаление защищенной ветви, удалить ее может любой пользователь, имеющий по крайней мере разрешения на запись в репозиторий.