Skip to main content

Сведения о защищенных ветвях

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

Защищенные ветви доступны в общедоступных репозиториях при использовании GitHub Free и GitHub Free для организаций, а также в общедоступных и частных репозиториях при использовании GitHub Pro, GitHub Team, GitHub Enterprise Cloud и GitHub Enterprise Server. Дополнительные сведения см. в разделе Продукты GitHub.

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

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

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

По умолчанию ограничения правила защиты ветви не применяются к пользователям с разрешениями администратора для репозитория или пользовательских ролей с разрешением "обход защиты ветви". При необходимости вы также можете применить ограничения к администраторам и ролям с разрешением "обход защиты ветви". Дополнительные сведения см. в статье Управление пользовательскими ролями репозитория для организации.

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

  1. Разрешить всем, у кого есть по крайней мере разрешения на запись в репозиторий, включая администраторов, выполнять принудительную отправку в ветвь.
  2. Разрешить выполнять принудительную отправку в ветвь только определенным пользователям или командам.

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

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

Разрешить удаления

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