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

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

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

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

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

Для определенной ветви, всех ветвей или любой ветви, которая соответствует шаблону имени, заданному с помощью синтаксиса fnmatch, можно создать правило защиты ветви в репозитории. Например, чтобы защитить все ветви, содержащие слово release, можно создать правило ветви для *release*. Дополнительные сведения о шаблонах имен ветви см. в разделе "Управление правилом защиты ветвей".

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

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

Для каждого правила защиты ветви можно включить или отключить приведенные ниже параметры.

• Требовать проверки запросов на вытягивание перед слиянием
• Требовать проверки состояния перед слиянием
• Требовать разрешение бесед перед слиянием
• Требовать подписанные фиксации
• Требовать линейную историю
• Требовать очередь слияния
• Требовать успешного развертывания перед слиянием
• Блокировка ветви
• Не разрешать обход указанных выше параметров
• Ограничить пользователей, которые могут выполнять отправку в соответствующие ветви
• Разрешить принудительные отправки
• Разрешить удаления

Дополнительные сведения о настройке защиты ветви см. в разделе "Управление правилом защиты ветвей".

Требовать проверки запросов на вытягивание перед слиянием

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

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

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

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

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

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

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

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

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

Кроме того, вы можете потребовать, чтобы последний отзывный push-запрос должен быть утвержден кем-то, кроме человека, который толкнул его. Это означает, что по крайней мере один другой авторизованный рецензент одобрил любые изменения. Например, "последний рецензент" может проверить, что последний набор изменений включает отзывы от других отзывов и не добавляет новое, неосмотримое содержимое.

Для сложных запросов на вытягивание, которые требуют многих отзывов, требуя утверждения от кого-то другого, кроме последнего человека, чтобы нажать на компромисс, который избегает необходимости отклонить все устаревшие проверки: с этим вариантом", "устаревшие" проверки не отклоняются, и запрос на вытягивание остается утвержденным до тех пор, пока кто-то другой, кроме человека, который сделал последние изменения утверждает его. Пользователи, которые уже проверили запрос на вытягивание, могут повторно применить после последней отправки, чтобы выполнить это требование. Если вы обеспокоены запросами на вытягивание "угон" (где неутвержденное содержимое добавляется в утвержденные запросы на вытягивание), это безопаснее, чтобы закрыть устаревшие проверки.

Требовать проверки состояния перед слиянием

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

С помощью API состояния фиксации можно разрешить внешним службам пометить фиксации соответствующим состоянием. Дополнительные сведения см. в разделе Конечные точки REST API для состояния фиксации.

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

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

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

Тип требуемой проверки состояния	Параметр	Требования к слиянию	Рекомендации
Строгий	Установлен флажок Требовать актуальность ветвей перед слиянием.	Перед слиянием ветвь должна быть обновлена в соответствии с базовой ветвью.	Это поведение по умолчанию для требуемых проверок состояния. Дополнительные сборки могут потребоваться, так как вам потребуется обновить главная ветвь после обновления целевой ветви другими участниками совместной работы.
Нестрогая	Флажок Требовать актуальность ветвей перед слиянием не установлен.	Перед слиянием ветвь не должна быть обновлена в соответствии с базовой ветвью.	У вас будет меньше требуемых сборок, так как вам не нужно будет обновлять главную ветвь после того, как другие участники совместной работы объединят запросы на вытягивание. При наличии изменений, несовместимых с главной ветвью, проверки состояния могут завершиться ошибкой после слияния ветви.
Отключен	Флажок Требовать прохождения проверок состояния перед слиянием****не установлен.	Ветвь не имеет ограничений на слияние.	Если требуемые проверки состояния не включены, участники совместной работы могут объединить ветвь в любое время независимо от того, обновлена ли она в соответствии с базовой ветвью. Это повышает вероятность возникновения несовместимых изменений.

Сведения об устранении неполадок см. в разделе "Устранение неполадок с обязательными проверками состояния".

Требовать устранения разногласий перед слиянием

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

Требовать подписанные фиксации

При включении обязательного подписывания фиксации в ветви участники совместной работы и боты могут отправлять в ветвь только подписанные и проверенные фиксации. Дополнительные сведения см. в разделе Сведения о проверке подписи фиксации.

• Если включен режим бдительности, указывающий, что фиксации всегда будут подписаны, все фиксации, которые GitHub идентифицирует как "Частично проверенные", разрешены в ветвях, требующих подписанных фиксаций. Дополнительные сведения о режиме бдения см. в разделе "Отображение состояний проверки для всех фиксаций".
• Если участник совместной работы отправляет неподписанную фиксацию в ветвь, требующую подписания фиксации, ему потребуется переместить изменения из одной ветви в другую, чтобы включить проверенную подпись, а затем принудительно отправить переписанную фиксацию в ветвь.

Вы всегда можете отправлять локальные фиксации в ветвь, если они подписаны и проверены. Вы можете также объединить подписанные и проверенные фиксации в ветвь с помощью запроса на вытягивание в GitHub Enterprise Cloud. Однако вы не можете объединить запрос на вытягивание в ветвь на GitHub Enterprise Cloud, если вы не являетесь автором запроса на вытягивание. Вы можете squash и объединить запросы на вытягивание локально. Дополнительные сведения см. в разделе Локальное получение для изменения запросов на вытягивание.

Дополнительные сведения о методах слияния см. в разделе "Сведения о методах слияния в GitHub".

Требовать линейный журнал

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

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

Требовать очередь слияния

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

Очередь слияния предоставляет те же преимущества, что и ветвей "Требовать актуальности" перед объединением защиты ветвей, но не требуется автор запроса на вытягивание для обновления ветви запроса на вытягивание и ожидания завершения проверки состояния, прежде чем пытаться объединиться.

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

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

Очередь слияния может использовать GitHub Actions или собственный поставщик CI для выполнения необходимых проверка для запросов на вытягивание в очереди слияния. Дополнительные сведения см. в разделе Документация GitHub Actions.

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

Требовать успешного развертывания перед слиянием

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

Блокировка ветви

Блокировка ветви сделает ветвь доступной только для чтения и гарантирует отсутствие фиксаций в ветви. Заблокированные ветви также не могут быть удалены.

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

Не разрешать обход указанных выше параметров

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

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

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

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

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

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

Вы можете предоставить права на отправку в защищенную ветвь или предоставить разрешение на создание соответствующей ветви только пользователям, командам или установленным GitHub Apps с доступом на запись в репозиторий. Пользователи и приложения с разрешениями администратора в репозитории всегда могут отправляться в защищенная ветвь или создать соответствующую ветвь.

Разрешить принудительные отправки

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

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

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

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

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

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