# Управление и стандартизация запросов на вытягивание

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

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

## Использование шаблонов запросов на вытягивание

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

Шаблоны полезны, когда многие участники открывают запросы на вытягивание или когда проект имеет ожидания проверки, которые должны отображаться каждый раз. См. раздел AUTOTITLE, AUTOTITLE\[ и \[AUTOTITLE[](/ru/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository). ]\(/get-started/writing-on-github/working-with-advanced-formatting/about-tasklists)]\(/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue)

## Определение владелец кода

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

Владельцы кода помогают направлять проверки пользователям с правильным контекстом. Они особенно полезны для конфиденциальных областей, таких как файлы безопасности, конфигурация развертывания или общие библиотеки. См [. раздел AUTOTITLE](/ru/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).

## Использование защищенная ветвь

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

Используйте защищенные ветви, когда ветвь представляет рабочий код, строку выпуска или другой важный источник истины. См [. раздел AUTOTITLE](/ru/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).

## Использование наборов правил

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

Наборы правил полезны, если требуется согласованные правила в нескольких ветвях или если требуется объединить требования к проверке безопасности с автоматическими проверками безопасности, например проверка зависимостей или code scanning защита слиянием. См. раздел AUTOTITLE, AUTOTITLE\[ и \[AUTOTITLE[](/ru/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets). ]\(/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review)]\(/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/set-merge-protection)

## Использование наборов правил push-уведомлений

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

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

Push-наборы правил позволяют выполнять следующие действия.

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

  Для этого можно использовать `fnmatch` синтаксис. Например, ограничение, предназначенное для `test/demo/**/*` предотвращения отправки в файлы или папки в `test/demo/` каталоге. Ограничение, предназначенное для `test/docs/pushrules.md` предотвращения отправки `pushrules.md` в файл в каталоге `test/docs/` . Дополнительные сведения см. в разделе [Создание наборов правил для репозитория](/ru/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax).
* **Ограничить длину пути к файлу:** запретить фиксации, включающие пути к файлам, превышающие указанное ограничение символов от отправки.
* **Ограничение расширений файлов.** Запретить отправку фиксаций, включающих файлы с указанными расширениями файлов.
* **Ограничение размера файла.** Запретить отправку фиксаций, превышающих указанное ограничение размера файла.

### Сведения о наборе правил push для вилированных репозиториев

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

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

Наборы правил push-уведомлений помогают блокировать рискованное содержимое перед вводом репозитория. См [. раздел AUTOTITLE](/ru/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets).

## Использование автоматизированных средств для просмотра стиля кода

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

Эти средства можно запускать как часть рабочего процесса непрерывной интеграции с GitHub Actions. См [. раздел AUTOTITLE](/ru/actions/get-started/continuous-integration).