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
使用推送规则集，可以阻止对专用或内部存储库的推送，以及对此存储库整个分支网络的推送，具体取决于文件扩展名、文件路径长度、文件和文件夹路径以及文件大小。
推送规则不需要针对任何分支，因为它们会应用于对存储库的每条推送。
推送规则集允许你：
-
限制文件路径：阻止推送包含指定文件路径更改的提交。
可以为此使用
fnmatch语法。 例如，针对test/demo/**/*的限制可阻止对test/demo/目录中的文件或文件夹进行任何推送。 针对test/docs/pushrules.md的限制可阻止对pushrules.md目录中test/docs/文件的专门推送。 有关详细信息，请参阅“创建存储库的规则集”。 -
限制文件路径长度：阻止推送包含超过指定字符限制的文件路径的提交。
-
限制文件扩展名：阻止推送包含具有指定文件扩展名的文件的提交。
-
限制文件大小：阻止推送超过指定文件大小限制的提交。
关于向已创建分支的存储库推送规则集
推送规则适用于存储库的整个分支网络，以确保存储库的每个入口点均受到保护。 例如，如果将已启用推送规则集的存储库创建为分支，则相同的推送规则集也适用于已创建分支的存储库。
对于已创建分支的存储库，只有对推送规则具有旁路权限的人员是根存储库中具有旁路权限的人员。
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 进行持续集成."