Вы можете создать наборы правил ветви или тегов, чтобы управлять взаимодействием пользователей с выбранными ветвями и тегами в репозитории. Вы также можете создавать наборы правил push-уведомлений для блокировки отправки в частный или внутренний репозиторий и всю сеть вилки этого репозитория.
При создании набора правил можно разрешить определенным пользователям обходить правила в наборе правил. Это могут быть пользователи с определенными ролями, определенными командами или GitHub Apps.
Для наборов правил push обхода применяются к репозиторию и всей сети вилки репозитория. Это означает, что единственными пользователями, которые могут обойти этот набор правил для любого репозитория в всей сети вилки этого репозитория, являются пользователи, которые могут обойти этот набор правил в корневом репозитории.
Дополнительные сведения о создании наборов правил и обходе разрешений см. в статье Создание наборов правил для репозиториев в организации](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository).
Ограничение создания
Если выбрано, только пользователи с разрешениями обхода могут создавать ветви или теги, имя которых соответствует указанному шаблону.
Ограничение обновлений
Если выбрано, только пользователи с разрешениями обхода могут отправляться в ветви или теги, имя которых соответствует указанному шаблону.
Ограничение удаления
Если выбрано, только пользователи с разрешениями обхода могут удалять ветви или теги, имя которых соответствует указанному шаблону. Это правило выбрано по умолчанию.
Требовать линейный журнал
Принудительное применение журнала линейной фиксации запрещает участникам совместной работы отправлять фиксации слиянием в целевые ветви или теги. Это означает, что любые запросы на вытягивание, объединенные в ветвь или тег, должны использовать слияние скваша или слияние повторной базы данных. Журнал строго линейной фиксации может помочь командам восстановить изменения проще. Дополнительные сведения о методах слияния см. в разделе Сведения о слиянии запросов на вытягивание.
Прежде чем требовать линейный журнал фиксаций, репозиторий должен разрешить слияние со сжатием или слияние с перемещением из одной ветви в другую. Дополнительные сведения см. в разделе Настройка слияния запросов на вытягивание.
Требовать успешного развертывания перед слиянием
Вы можете потребовать успешного развертывания изменений в определенные среды, прежде чем можно будет выполнить слияние ветви. Например, это правило можно использовать для успешного развертывания изменений в промежуточную среду перед слиянием изменений в ветвь по умолчанию.
Требовать подписанные фиксации
При включении обязательного подписывания фиксации в ветви участники совместной работы и боты могут отправлять в ветвь только подписанные и проверенные фиксации. Дополнительные сведения см. в разделе Сведения о проверке подписи фиксации.
Правила защиты ветви и наборы правил работают по-разному при создании ветви: с наборами правил мы проверяем только фиксации, недоступные из других ветвей, в то время как при использовании правил защиты ветви мы не проверяем подписанные фиксации, если только вы не ограничиваете отправки, которые создают соответствующие ветви. При обновлении ветви мы по-прежнему проверяем все фиксации в указанном диапазоне, даже если фиксация недоступна из других ветвей.
С обоими методами мы используем verified_signature? для подтверждения наличия допустимой подписи фиксации. Если нет, обновление не принимается.
Примечание.
- Если вы включили режим бдительности в параметрах учетной записи, которые указывают на то, что фиксации всегда будут подписаны, все фиксации, которые GitHub идентифицируются как "Частично проверенные" в ветвях, для которых требуются подписанные фиксации. Дополнительные сведения о режиме бдения см. в разделе Отображение состояний проверки для всех фиксаций.
- Если участник совместной работы отправляет неподписанную фиксацию в ветвь, требующую подписания фиксации, ему потребуется переместить изменения из одной ветви в другую, чтобы включить проверенную подпись, а затем принудительно отправить переписанную фиксацию в ветвь.
Вы всегда можете отправлять локальные фиксации в ветвь, если они подписаны и проверены. Вы также можете объединить подписанные и проверенные фиксации в ветвь с помощью запроса на вытягивание. Однако вы не можете скваш и объединить запрос на вытягивание в ветвь на GitHub, если вы не являетесь автором запроса на вытягивание. Вы можете squash и объединить запросы на вытягивание локально. Дополнительные сведения см. в разделе Локальное получение для изменения запросов на вытягивание.
Дополнительные сведения о методах слияния см. в разделе О методах слияния на GitHub.
Требовать запрос на вытягивание перед слиянием
Вы можете требовать, чтобы все изменения в целевой ветви были связаны с запросом на вытягивание. Запрос на вытягивание не обязательно должен быть утвержден, но его необходимо открыть.
Дополнительные параметры
Примечание.
Если при отправке новых фиксаций при отправке новых фиксаций и (или ) требовать утверждения последней проверяемой отправки вручную создание фиксации слияния для запроса на вытягивание и отправка ее непосредственно в защищенная ветвь завершится ошибкой, если содержимое слияния точно не соответствует слиянию, созданному GitHub для запроса на вытягивание.
Кроме того, при использовании этих параметров утверждения проверки будут отклонены как устаревшие, если база слияния вводит новые изменения после отправки проверки. База слияния — это фиксация, которая является последним общим предком между ветвью раздела и базовая ветвь. Если база слиянием изменяется, запрос на вытягивание не может быть объединен до тех пор, пока кто-то не утвердит работу снова.
Администраторы репозитория или пользовательские роли с разрешением "Изменить правила репозитория" могут требовать, чтобы все запросы на вытягивание получали определенное количество утверждений, прежде чем кто-то объединяет запрос на вытягивание в защищенная ветвь. Вы можете требовать утверждения проверок от пользователей с разрешениями на запись в репозиторий или от назначенного владельца кода.
Если включить необходимые проверки, сотрудники могут отправлять изменения в ветвь только с помощью запроса на вытягивание, утвержденного требуемым количеством рецензентов с разрешениями на запись.
Если кто-то выбирает вариант изменения запроса в проверке, то этот пользователь должен утвердить запрос на вытягивание перед объединением запроса на вытягивание. Если рецензент, требующий изменения для запроса на вытягивание, недоступен, любой пользователь с разрешениями на запись в репозиторий может отклонить блокирующую проверку.
Даже если все обязательные проверяющие одобрили запрос на вытягивание, участники совместной работы не могут выполнить слияние для запроса на вытягивание, если есть другие открытые запросы на вытягивание, имеющие главную ветвь, указывающую на ту же фиксацию с ожидающими или отклоненными проверками. Кто-то с разрешениями на запись сначала должен утвердить или закрыть блокировку проверки на другие запросы на вытягивание.
При необходимости можно закрыть утверждения устаревших запросов на вытягивание при отправке фиксаций, влияющих на дифф в запросе на вытягивание. GitHub записывает состояние диффа в момент утверждения запроса на вытягивание. Это состояние представляет набор изменений, утвержденных рецензентом. Если дифф изменяется из этого состояния (например, так как участник отправляет новые изменения в ветвь запроса на вытягивание или щелкает ветвь обновления или связанная запрос на вытягивание объединяется в целевую ветвь), утверждение отзыва закрывается как устаревший, и запрос на вытягивание не может быть объединен, пока кто-то не утвердит работу снова. Сведения о целевой ветви см. в разделе Сведения о запросах на вытягивание.
При необходимости можно требовать проведение проверок от владельцев кода. Если это сделать, любой запрос на вытягивание, который изменяет содержимое с помощью владелец кода, должен быть утвержден этим владелец кода, прежде чем запрос на вытягивание можно будет объединить в защищенная ветвь. Обратите внимание, что если код имеет несколько владельцев, утверждение от любого из владелец кода будет достаточно для удовлетворения этого требования. Дополнительные сведения см. в разделе О владельцах кода.
При необходимости вы можете требовать от кого-то другого пользователя утверждение, отличного от последнего пользователя, чтобы отправить в ветвь, прежде чем запрос на вытягивание можно объединить. Это означает, что по крайней мере один другой авторизованный рецензент одобрил любые изменения. Например, "последний рецензент" может проверить, что последний набор изменений включает отзывы от других отзывов и не добавляет новое, неосмотримое содержимое.
Для сложных запросов на вытягивание, которые требуют многих отзывов, требуя утверждения от кого-то другого, кроме последнего человека, чтобы нажать на компромисс, который избегает необходимости отклонить все устаревшие проверки: с этим вариантом", "устаревшие" проверки не отклоняются, и запрос на вытягивание остается утвержденным до тех пор, пока кто-то другой, кроме человека, который сделал последние изменения утверждает его. Пользователи, которые уже проверили запрос на вытягивание, могут повторно применить после последней отправки, чтобы выполнить это требование. Если вы обеспокоены запросами на вытягивание "угон" (где неутвержденное содержимое добавляется в утвержденные запросы на вытягивание), это безопаснее, чтобы закрыть устаревшие проверки.
При необходимости можно требовать разрешение всех примечаний к запросу на вытягивание, прежде чем его можно объединить с ветвью. Это гарантирует, что перед слиянием все комментарии будут разрешены или подтверждены.
При необходимости можно требовать тип слияния слиянием, сквош или перебазу. Это означает, что целевые ветви могут быть объединены только на основе разрешенного типа. Кроме того, если репозиторий отключил метод слияния и набор правил, необходимый другой метод, слияние будет заблокировано. См . раздел AUTOTITLE.
Обязательные рецензенты
По желанию, вы можете требовать проверку или одобрение от конкретных команд, если pull request меняет определённые файлы или каталоги. Вы можете выбрать до 15 разных команд, и для каждой команды потребуется определённое количество одобрений от членов команды.
Выпадающее меню Reviewer позволяет выбрать любую команду, которая входит в область действия правила.
-
**Правила всей организации**: команда должна принадлежать организации. -
**Правила на уровне репозитория**: команда должна принадлежать организации, которой владеет репозиторий.
Это правило недоступно в пользовательских репозиториях, так как в них нет команд.
Обязательные одобрения могут быть установлены от 0 (0) до 10. Отсутствие необходимости одобрения означает, что команда будет добавлена для видимости, но команда не обязана одобрять запрос.
Для каждой команды можно задать список шаблонов файлов, который определяет, к каким файлам применяется эта настройка. Формат этого списка файлов совпадает со стандартным .gitignore файлом:
- Узор, начинающийся с восклицательного знака (
!) — это отрицание. Это приведёт к тому, что пути, соответствующие более ранним шаблонам, не будут требовать одобрения. - Паттерны сопоставляются по порядку, поэтому отрицаемые паттерны могут «развлекать» файлы, соответствовавшие предыдущим правилам.
Обязательное прохождение проверок состояния перед слиянием
Обязательные проверки состояния убедитесь, что все необходимые тесты CI передаются, прежде чем сотрудники смогут вносить изменения в ветвь или тег, предназначенный для набора правил. Обязательные проверки состояния могут быть проверками или состояниями. Дополнительные сведения см. в разделе Сведения о проверках состояния.
С помощью API состояния фиксации можно разрешить внешним службам пометить фиксации соответствующим состоянием. Дополнительные сведения см. в разделе Конечные точки REST API для состояния фиксации.
После включения обязательная проверка состояния все обязательная проверка состояния должны передаваться, прежде чем сотрудники могут объединить изменения в ветвь или тег.
Любой пользователь или интеграция с разрешениями на запись в репозиторий может задать состояние проверки состояния в репозитории, но в некоторых случаях может потребоваться только принять проверку состояния из определенного GitHub App. При добавлении правила обязательная проверка состояния можно выбрать приложение в качестве ожидаемого источника обновлений состояния. Приложение должно быть установлено в репозитории с statuses:write разрешением, должно быть недавно отправлено выполнение проверки и должно быть связано с предварительно существующим обязательная проверка состояния в наборе правил. Если состояние задано любым другим человеком или интеграцией, слияние не будет разрешено. Если выбрать "любой источник", вы по-прежнему можете вручную проверить автора каждого состояния, указанного в поле слияния.
Чтобы устранить неполадки при настройке проверки состояния в наборе правил, см. раздел AUTOTITLE.
Вы можете думать о обязательная проверка состояния как "свободный" или "строгий". Выбранный тип требуемой проверки состояния определяет, должна ли ваша ветвь быть обновлена в соответствии с базовой ветвью перед слиянием.
| Тип требуемой проверки состояния | Параметр | Требования к слиянию | Рекомендации |
|---|
**Строгий** | Установлен флажок **Требовать актуальность ветвей перед слиянием**. | Перед слиянием ветвь **раздела должна** быть обновлена базовая ветвь. | Это поведение по умолчанию для требуемых проверок состояния. Дополнительные сборки могут потребоваться, так как вам потребуется обновить главная ветвь после обновления целевой ветви другими участниками совместной работы.|
| Нестрогая | Флажок Требовать актуальность ветвей перед слиянием****не установлен. | Перед слиянием ветвь не должна быть обновлена в соответствии с базовой ветвью. | У вас будет меньше требуемых сборок, так как вам не нужно будет обновлять главную ветвь после того, как другие участники совместной работы объединят запросы на вытягивание. При наличии изменений, несовместимых с главной ветвью, проверки состояния могут завершиться ошибкой после слияния ветви. | | Отключен | Флажок Требовать прохождения проверок состояния перед слиянием****не установлен. | Ветвь не имеет ограничений на слияние. | Если требуемые проверки состояния не включены, участники совместной работы могут объединить ветвь в любое время независимо от того, обновлена ли она в соответствии с базовой ветвью. Это повышает вероятность возникновения несовместимых изменений.
Сведения об устранении неполадок с состоянием см. в разделе Устранение неполадок с обязательными проверками состояния.
Блокирование принудительной отправки
Вы можете запретить пользователям принудительная отправка в целевые ветви или теги. Это правило включено по умолчанию.
Если кто-то принудительная отправка в ветвь или тег, зафиксирует, что другие сотрудники на основе своей работы могут быть удалены из истории ветви или тега. Это может привести к конфликт слияния или поврежденным запросам на вытягивание. Принудительное принудительное отправку также можно использовать для удаления ветвей или указания ветви на фиксации, которые не были утверждены в запросе на вытягивание.
Включение принудительная отправка не переопределяет другие правила. Например, если ветви требуется линейный журнал фиксаций, принудительно отправлять фиксации слияния в эту ветвь невозможно.
Требуется code scanning результатов
Если репозитории настроены с помощью code scanning, можно использовать наборы правил, чтобы предотвратить объединение запросов на вытягивание при выполнении одного из следующих условий:
- Требуемый инструмент находит code scanning оповещение о тяжести, определённой в наборе правил.
- Анализ необходимого инструмента всё ещё продолжается.
- Требуемый инструмент не настроен для репозитория.
Дополнительные сведения см. в разделе Настройка защиты от сканирования кода слиянием. Дополнительные сведения о code scanningсм. в разделе Сведения о проверке кода.
Ограничение путей к файлам
Запретить фиксации, включающие изменения в указанные пути к файлам, отправляться в репозиторий. Ограничение составляет 200 записей и до 200 символов в каждой записи.
Для этого можно использовать fnmatch синтаксис. Например, ограничение, предназначенное для test/demo/**/* предотвращения отправки в файлы или папки в test/demo/ каталоге. Ограничение, предназначенное для test/docs/pushrules.md предотвращения отправки pushrules.md в файл в каталоге test/docs/ . Дополнительные сведения см. в разделе Создание наборов правил для репозитория.
Ограничение длины пути к файлу
Запрет фиксаций, включающих пути к файлам, превышающие указанное ограничение символов, отправляется в репозиторий.
Ограничение расширений файлов
Запретить фиксации, включающие файлы с указанными расширениями файлов, отправляться в репозиторий. Ограничение составляет 200 записей и до 200 символов в каждой записи.
Ограничение размера файла
Запретить фиксации, превышающие указанное ограничение размера файла, отправляться в репозиторий.