If you maintain a repository, you can use GitHub features to make pull requests more consistent and easier to review. Standardization helps contributors know what information to provide, helps reviewers focus on the right changes, and helps protect important branches from accidental or risky merges.
Using pull request templates
Pull request templates help contributors provide the context your project needs for review. A template can prompt authors to explain the purpose of the change, link related issues, include testing notes, or complete a checklist before requesting review.
Templates are useful when many contributors open pull requests or when your project has review expectations that should be visible every time. See 为仓库创建拉取请求模板, 关于任务列表, and 将拉取请求链接到议题.
Defining code owners
Code owners identify the people or teams responsible for specific files or directories. When a pull request changes owned code, GitHub can automatically request a review from the right owners.
Code owners help route reviews to people with the right context. They are especially useful for sensitive areas such as security files, deployment configuration, or shared libraries. See 关于代码所有者.
Using protected branches
Protected branches help keep important branches, such as main, stable. They can require conditions such as passing status checks, signed commits, or approving reviews before a pull request can merge.
Use protected branches when a branch represents production code, a release line, or another important source of truth. See 关于受保护分支.
Using rulesets
Rulesets let you enforce repository policies across branches and tags. They can require status checks, workflows, pull request reviews, or other conditions before changes are accepted.
Rulesets are useful when you want consistent rules across multiple branches or when you want to combine review requirements with automated security checks, such as dependency review or code scanning merge protection. See 关于规则集, 在整个组织内强制执行依赖项审查, and 设置代码扫描合并保护.
Using push rulesets
使用推送规则集，可以阻止对专用或内部存储库的推送，以及对此存储库整个分支网络的推送，具体取决于文件扩展名、文件路径长度、文件和文件夹路径以及文件大小。
推送规则不需要针对任何分支，因为它们会应用于对存储库的每条推送。
推送规则集允许你：
-
限制文件路径：阻止推送包含指定文件路径更改的提交。
可以为此使用
fnmatch语法。 例如，针对test/demo/**/*的限制可阻止对test/demo/目录中的文件或文件夹进行任何推送。 针对test/docs/pushrules.md的限制可阻止对pushrules.md目录中test/docs/文件的专门推送。 有关详细信息，请参阅“创建存储库的规则集”。 -
限制文件路径长度：阻止推送包含超过指定字符限制的文件路径的提交。
-
限制文件扩展名：阻止推送包含具有指定文件扩展名的文件的提交。
-
限制文件大小：阻止推送超过指定文件大小限制的提交。
关于向已创建分支的存储库推送规则集
推送规则适用于存储库的整个分支网络，以确保存储库的每个入口点均受到保护。 例如，如果将已启用推送规则集的存储库创建为分支，则相同的推送规则集也适用于已创建分支的存储库。
对于已创建分支的存储库，只有对推送规则具有旁路权限的人员是根存储库中具有旁路权限的人员。
Push rulesets help block risky content before it enters the repository. See 关于规则集.
Using automated tools to review code styling
Automated tools, such as linters and formatters, help keep code style consistent across pull requests. They can catch small issues automatically so reviewers can focus on design, correctness, and maintainability.
You can run these tools as part of a continuous integration workflow with GitHub Actions. See 持续集成.
