Вы можете создать наборы правил ветви или тегов, чтобы управлять взаимодействием пользователей с выбранными ветвями и тегами в репозитории. Вы также можете создавать push-наборы правил, чтобы блокировать push-запросы в приватный или внутренний репозиторий и всю сеть форков этого репозитория.
При создании набора правил можно разрешить определенным пользователям обходить правила в наборе правил. Это могут быть пользователи с определёнными ролями, конкретные команды или GitHub Apps.
Для наборов правил push обхода применяются к репозиторию и всей сети вилки репозитория. Это означает, что единственными пользователями, которые могут обойти этот набор правил для любого репозитория в всей сети вилки этого репозитория, являются пользователи, которые могут обойти этот набор правил в корневом репозитории.
Для получения дополнительной информации о создании наборов правил и правах на обход см. Создание наборов правил для репозитория.
Ограничение создания
Если выбрано, только пользователи с разрешениями обхода могут создавать ветви или теги, имя которых соответствует указанному шаблону.
Ограничение обновлений
Если выбрано, только пользователи с разрешениями обхода могут отправляться в ветви или теги, имя которых соответствует указанному шаблону.
Ограничение удаления
Если выбрано, только пользователи с разрешениями обхода могут удалять ветви или теги, имя которых соответствует указанному шаблону. Это правило выбрано по умолчанию.
Требовать линейный журнал
Принудительное применение журнала линейной фиксации запрещает участникам совместной работы отправлять фиксации слиянием в целевые ветви или теги. Это означает, что любые запросы на вытягивание, объединенные в ветвь или тег, должны использовать слияние скваша или слияние повторной базы данных. Журнал строго линейной фиксации может помочь командам восстановить изменения проще. Дополнительные сведения о методах слияния см. в разделе Сведения о слиянии запросов на вытягивание.
Прежде чем требовать линейный журнал фиксаций, репозиторий должен разрешить слияние со сжатием или слияние с перемещением из одной ветви в другую. Дополнительные сведения см. в разделе Настройка слияния запросов на вытягивание.
Требовать успешного развертывания перед слиянием
Вы можете потребовать успешного развертывания изменений в определенные среды, прежде чем можно будет выполнить слияние ветви. Например, это правило можно использовать для успешного развертывания изменений в промежуточную среду перед слиянием изменений в ветвь по умолчанию.
Требовать подписанные фиксации
Когда вы включили обязательное подписание коммита на ветке, участники и боты могут отправлять только те коммиты, которые были подписаны и проверены. Дополнительные сведения см. в разделе Сведения о проверке подписи фиксации.
Правила защиты ветви и наборы правил работают по-разному при создании ветви: с наборами правил мы проверяем только фиксации, недоступные из других ветвей, в то время как при использовании правил защиты ветви мы не проверяем подписанные фиксации, если только вы не ограничиваете отправки, которые создают соответствующие ветви. При обновлении ветви мы по-прежнему проверяем все фиксации в указанном диапазоне, даже если фиксация недоступна из других ветвей.
С обоими методами мы используем verified_signature? для подтверждения наличия допустимой подписи фиксации. Если нет, обновление не принимается.
Примечание.
- Если вы включили режим бдительности в настройках аккаунта, который показывает, что ваши коммиты всегда будут подписаны, любые коммиты, GitHub идентифицирующие себя как «Частично проверенные», разрешены в филиалах, требующих подписанных коммитов. Дополнительные сведения о режиме бдения см. в разделе Отображение состояний проверки для всех фиксаций.
- Если участник совместной работы отправляет неподписанную фиксацию в ветвь, требующую подписания фиксации, ему потребуется переместить изменения из одной ветви в другую, чтобы включить проверенную подпись, а затем принудительно отправить переписанную фиксацию в ветвь.
Вы всегда можете отправлять локальные фиксации в ветвь, если они подписаны и проверены. Вы также можете объединить подписанные и верифицированные коммиты в ветку с помощью pull-запроса. Однако вы не можете сжать и объединить pull-запрос с веткой, GitHub если вы не являетесь автором pull request. Вы можете локально сквашить и объединять pull-запросы. Дополнительные сведения см. в разделе Локальное получение для изменения запросов на вытягивание.
Для получения дополнительной информации о методах слияния см. АВТОТИТРЫ.
Требовать запрос на вытягивание перед слиянием
Вы можете требовать, чтобы все изменения в целевой ветви были связаны с запросом на вытягивание. Запрос на вытягивание не обязательно должен быть утвержден, но его необходимо открыть.
Дополнительные параметры
Примечание.
Если при отправке новых фиксаций при отправке новых фиксаций и (или ) требовать утверждения последней проверяемой отправки вручную создание фиксации слияния для запроса на вытягивание и отправка ее непосредственно в защищенная ветвь завершится ошибкой, если содержимое слияния точно не соответствует слиянию, созданному GitHub для запроса на вытягивание.
Кроме того, при использовании этих параметров утверждения проверки будут отклонены как устаревшие, если база слияния вводит новые изменения после отправки проверки. База слияния — это фиксация, которая является последним общим предком между ветвью раздела и базовая ветвь. Если база слиянием изменяется, запрос на вытягивание не может быть объединен до тех пор, пока кто-то не утвердит работу снова.
Администраторы репозитория или пользовательские роли с разрешением "Изменить правила репозитория" могут требовать, чтобы все запросы на вытягивание получали определенное количество утверждений, прежде чем кто-то объединяет запрос на вытягивание в защищенная ветвь. Вы можете требовать утверждения проверок от пользователей с разрешениями на запись в репозиторий или от назначенного владельца кода.
Если включить необходимые проверки, сотрудники могут отправлять изменения в ветвь только с помощью запроса на вытягивание, утвержденного требуемым количеством рецензентов с разрешениями на запись.
Если кто-то выбирает вариант изменения запроса в проверке, то этот пользователь должен утвердить запрос на вытягивание перед объединением запроса на вытягивание. Если рецензент, требующий изменения для запроса на вытягивание, недоступен, любой пользователь с разрешениями на запись в репозиторий может отклонить блокирующую проверку.
Даже если все обязательные проверяющие одобрили запрос на вытягивание, участники совместной работы не могут выполнить слияние для запроса на вытягивание, если есть другие открытые запросы на вытягивание, имеющие главную ветвь, указывающую на ту же фиксацию с ожидающими или отклоненными проверками. Кто-то с разрешениями на запись сначала должен утвердить или закрыть блокировку проверки на другие запросы на вытягивание.
При необходимости можно закрыть утверждения устаревших запросов на вытягивание при отправке фиксаций, влияющих на дифф в запросе на вытягивание. GitHub Фиксирует состояние дифференциала в момент одобрения pull request. Это состояние представляет набор изменений, утвержденных рецензентом. Если дифф изменяется из этого состояния (например, так как участник отправляет новые изменения в ветвь запроса на вытягивание или щелкает ветвь обновления или связанная запрос на вытягивание объединяется в целевую ветвь), утверждение отзыва закрывается как устаревший, и запрос на вытягивание не может быть объединен, пока кто-то не утвердит работу снова. Сведения о целевой ветви см. в разделе Сведения о запросах на вытягивание.
При необходимости можно требовать проведение проверок от владельцев кода. Если это сделать, любой запрос на вытягивание, который изменяет содержимое с помощью владелец кода, должен быть утвержден этим владелец кода, прежде чем запрос на вытягивание можно будет объединить в защищенная ветвь. Обратите внимание, что если код имеет несколько владельцев, утверждение от любого из владелец кода будет достаточно для удовлетворения этого требования. Дополнительные сведения см. в разделе О владельцах кода.
При необходимости вы можете требовать от кого-то другого пользователя утверждение, отличного от последнего пользователя, чтобы отправить в ветвь, прежде чем запрос на вытягивание можно объединить. Это означает, что по крайней мере один другой авторизованный рецензент одобрил любые изменения. Например, "последний рецензент" может проверить, что последний набор изменений включает отзывы от других отзывов и не добавляет новое, неосмотримое содержимое.
Для сложных запросов на вытягивание, которые требуют многих отзывов, требуя утверждения от кого-то другого, кроме последнего человека, чтобы нажать на компромисс, который избегает необходимости отклонить все устаревшие проверки: с этим вариантом", "устаревшие" проверки не отклоняются, и запрос на вытягивание остается утвержденным до тех пор, пока кто-то другой, кроме человека, который сделал последние изменения утверждает его. Пользователи, которые уже проверили запрос на вытягивание, могут повторно применить после последней отправки, чтобы выполнить это требование. Если вы обеспокоены запросами на вытягивание "угон" (где неутвержденное содержимое добавляется в утвержденные запросы на вытягивание), это безопаснее, чтобы закрыть устаревшие проверки.
При необходимости можно требовать разрешение всех примечаний к запросу на вытягивание, прежде чем его можно объединить с ветвью. Это гарантирует, что перед слиянием все комментарии будут разрешены или подтверждены.
По желанию можно потребовать слияние, сквош или ребейс. Это означает, что целевые ветви могут быть объединены только на основе разрешенного типа. Кроме того, если репозиторий отключил метод слияния и набор правил, необходимый другой метод, слияние будет заблокировано. См . раздел AUTOTITLE.
Обязательные рецензенты
По желанию, вы можете требовать проверку или одобрение от конкретных команд, если pull request меняет определённые файлы или каталоги. Вы можете выбрать до 15 разных команд, и для каждой команды потребуется определённое количество одобрений от членов команды. Чтобы одобрение от члена команды засчитывалось, команда должна иметь права на запись (или выше) для репозитория.
Выпадающее меню Reviewer позволяет выбрать любую команду, которая входит в область действия правила.
- Правила всей организации: команда должна принадлежать организации.
- Правила на уровне репозитория: команда должна принадлежать организации, которой владеет репозиторий.
Это правило недоступно в пользовательских репозиториях, так как в них нет команд.
Обязательные одобрения могут быть установлены от 0 (0) до 10. Отсутствие необходимости одобрения означает, что команда будет добавлена для видимости, но команда не обязана одобрять запрос.
Для каждой команды можно задать список шаблонов файлов, который определяет, к каким файлам применяется эта настройка. Формат этого списка файлов совпадает со стандартным .gitignore файлом:
- Узор, начинающийся с восклицательного знака (
!) — это отрицание. Это приведёт к тому, что пути, соответствующие более ранним шаблонам, не будут требовать одобрения. - Паттерны сопоставляются по порядку, поэтому отрицаемые паттерны могут «развлекать» файлы, соответствовавшие предыдущим правилам.
Обязательное прохождение проверок состояния перед слиянием
Обязательные проверки состояния убедитесь, что все необходимые тесты CI передаются, прежде чем сотрудники смогут вносить изменения в ветвь или тег, предназначенный для набора правил. Обязательные проверки состояния могут быть проверками или состояниями. Дополнительные сведения см. в разделе Сведения о проверках состояния.
С помощью API состояния фиксации можно разрешить внешним службам пометить фиксации соответствующим состоянием. Дополнительные сведения см. в разделе Конечные точки REST API для состояния фиксации.
После включения обязательная проверка состояния все обязательная проверка состояния должны передаваться, прежде чем сотрудники могут объединить изменения в ветвь или тег.
Любой человек или интеграция с правами записи в репозиторий может задать состояние любой проверки статуса в репозитории, но в некоторых случаях вы можете захотеть принять только проверку статуса от конкретного GitHub App. При добавлении правила обязательная проверка состояния можно выбрать приложение в качестве ожидаемого источника обновлений состояния. Приложение должно быть установлено в репозитории с statuses:write разрешением, должно быть недавно отправлено выполнение проверки и должно быть связано с предварительно существующим обязательная проверка состояния в наборе правил. Если состояние задано любым другим человеком или интеграцией, слияние не будет разрешено. Если выбрать "любой источник", вы по-прежнему можете вручную проверить автора каждого состояния, указанного в поле слияния.
Чтобы устранить неполадки при настройке проверки состояния в наборе правил, см. раздел AUTOTITLE.
Вы можете думать о обязательная проверка состояния как "свободный" или "строгий". Выбранный тип требуемой проверки состояния определяет, должна ли ваша ветвь быть обновлена в соответствии с базовой ветвью перед слиянием.
| Тип требуемой проверки состояния | Параметр | Требования к слиянию | Рекомендации |
|---|---|---|---|
| Строгий | Установлен флажок Требовать актуальность ветвей перед слиянием. | Перед слиянием ветвь раздела должна быть обновлена базовая ветвь. | Это поведение по умолчанию для требуемых проверок состояния. Дополнительные сборки могут потребоваться, так как вам потребуется обновить главная ветвь после обновления целевой ветви другими участниками совместной работы. |
| Нестрогая | Флажок Требовать актуальность ветвей перед слиянием****не установлен. | Перед слиянием ветвь не должна быть обновлена в соответствии с базовой ветвью. | У вас будет меньше требуемых сборок, так как вам не нужно будет обновлять главную ветвь после того, как другие участники совместной работы объединят запросы на вытягивание. При наличии изменений, несовместимых с главной ветвью, проверки состояния могут завершиться ошибкой после слияния ветви. |
| Отключен | Флажок Требовать прохождения проверок состояния перед слиянием****не установлен. | Ветвь не имеет ограничений на слияние. | Если требуемые проверки состояния не включены, участники совместной работы могут объединить ветвь в любое время независимо от того, обновлена ли она в соответствии с базовой ветвью. Это повышает вероятность возникновения несовместимых изменений. |
Сведения об устранении неполадок с состоянием см. в разделе Устранение неполадок с обязательными проверками состояния.
Блокирование принудительной отправки
Вы можете запретить пользователям принудительная отправка в целевые ветви или теги. Это правило включено по умолчанию.
Если кто-то принудительная отправка в ветвь или тег, зафиксирует, что другие сотрудники на основе своей работы могут быть удалены из истории ветви или тега. Это может привести к конфликт слияния или поврежденным запросам на вытягивание. Принудительное принудительное отправку также можно использовать для удаления ветвей или указания ветви на фиксации, которые не были утверждены в запросе на вытягивание.
Включение принудительная отправка не переопределяет другие правила. Например, если ветви требуется линейный журнал фиксаций, принудительно отправлять фиксации слияния в эту ветвь невозможно.
Требуется code scanning результат
Если ваши репозитории настроены на code scanning, вы можете использовать наборы правил, чтобы предотвратить слияние pull request, если выполнено одно из следующих условий:
- Требуемый инструмент находит code scanning оповещение о тяжести, определённой в наборе правил.
- Анализ необходимого инструмента всё ещё продолжается.
- Требуемый инструмент не настроен для репозитория.
Дополнительные сведения см. в разделе Настройка защиты от сканирования кода слиянием. Для более общей информации о code scanning, см. Code scanning.
Требовать результаты качества кода
Если ваши репозитории настроены на GitHub Code Quality, вы можете использовать наборы правил, чтобы предотвратить слияние pull request, если выполнено одно из следующих условий:
- Анализ все еще продолжается.
- Анализ не проходит по какой-либо причине, например: вы исчерпали свой бюджет на минуты действий.
- Code Quality обнаружено из-за тяжести уровня, определённого в правилах, или более высокой тяжести.
Дополнительные сведения см. в разделе [AUTOTITLE и О качестве кода на GitHub](/code-security/code-quality/how-tos/set-pr-thresholds).
Ограничение путей к файлам
Запретить фиксации, включающие изменения в указанные пути к файлам, отправляться в репозиторий. Лимит — 200 записей и до 200 символов в каждой записи.
Для этого можно использовать fnmatch синтаксис. Например, ограничение, предназначенное для test/demo/**/* предотвращения отправки в файлы или папки в test/demo/ каталоге. Ограничение, предназначенное для test/docs/pushrules.md предотвращения отправки pushrules.md в файл в каталоге test/docs/ . Дополнительные сведения см. в разделе Создание наборов правил для репозитория.
Ограничение длины пути к файлу
Запрет фиксаций, включающих пути к файлам, превышающие указанное ограничение символов, отправляется в репозиторий.
Ограничение расширений файлов
Запретить фиксации, включающие файлы с указанными расширениями файлов, отправляться в репозиторий. Лимит — 200 записей и до 200 символов в каждой записи.
Ограничение размера файла
Запретить фиксации, превышающие указанное ограничение размера файла, отправляться в репозиторий.