Managing and standardizing pull requests

Use these steps to manage and standardize the pull requests that contributors create in your repository.

В этой статье

If you are a repository maintainer, there are several ways that you can manage and standardize the pull requests that contributors create in your repository. These steps can help you ensure that pull requests are reviewed by the right people, and that they meet your repository's standards.

Using pull request templates

Pull request templates let you customize and standardize the information you'd like to be included when someone creates a pull request in your repository. When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body. For more information, see "Создание шаблона запроса на вытягивание для репозитория."

You can use pull request templates to standardize the review process for your repository. For example, you can include a list of tasks that you would like authors to complete before merging their pull requests, by adding a task list to the template. For more information, see "Сведения о списках задач."

You can request that contributors include an issue reference in their pull request body, so that merging the pull request will automatically close the issue. For more information, see "Связывание запроса на вытягивание с проблемой."

Defining code owners

You may want to make sure that specific individuals always review changes to certain code or files in your repository. For example, you may want a technical writer on your team to always review changes in the docs directory.

You can define individuals or teams that you consider responsible for code or files in a repository to be code owners. Code owners will automatically be requested for review when someone opens a pull request that modifies the files that they own. You can define code owners for specific types of files or directories, as well as for different branches in a repository. For more information, see "О владельцах кода."

Using protected branches

You can use protected branches to prevent pull requests from being merged into important branches, such as main, until certain conditions are met. For example, you can require passing CI tests or an approving review. For more information, see "Сведения о защищенных ветвях."

Using push rulesets

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

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

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

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

    Для этого можно использовать fnmatch синтаксис. Например, ограничение, предназначенное для test/demo/**/* предотвращения отправки в файлы или папки в test/demo/ каталоге. Ограничение, предназначенное для test/docs/pushrules.md предотвращения отправки pushrules.md в файл в каталоге test/docs/ . Дополнительные сведения см. в разделе «Создание наборов правил для репозитория».

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

  • Ограничение расширений файлов. Запретить отправку фиксаций, включающих файлы с указанными расширениями файлов.

  • Ограничение размера файла. Запретить отправку фиксаций, превышающих указанное ограничение размера файла.

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

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

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

For more information, see "Сведения о наборе правил."

Using automated tools to review code styling

Use automated tools, such as linters, in your repository's pull requests to maintain consistent styling and make code more understandable. Using automated tools to catch smaller problems like typos or styling leaves more time for reviewers to focus on the substance of a pull request.

For example, you can use GitHub Actions to set up code linters that can run on pull requests as part of your continuous integration (CI) workflow. For more information, see "Сведения о непрерывной интеграции с GitHub Actions."