创建拉取请求的最佳实践
创建拉取请求时，请遵循以下一些最佳实践，以获得更流畅的审查流程。有关创建拉取请求的信息，请参阅“创建拉取请求”。
编写小型 PR
目标是创建小型、专注的拉取请求，以实现单一目的。较小的拉取请求更易于且更快地审查和合并，减少引入错误的空间，并提供更清晰的更改历史记录。
首先审查您自己的拉取请求
在提交拉取请求之前，请先审查、构建和测试您自己的拉取请求。这将使您能够在其他人开始审查之前捕获您可能错过的错误或错别字。
提供上下文和指导
为您的拉取请求编写清晰的标题和描述，以便审阅者能够快速了解拉取请求的作用。在拉取请求正文中，包括
- 拉取请求的目的
- 更改概述
- 指向任何其他上下文的链接，例如跟踪问题或以前的对话
为了帮助审阅者，请分享您需要的反馈类型。例如，您需要快速浏览还是更深入的批评？
如果您的拉取请求包含对多个文件的更改，请为审阅者提供有关审查文件顺序的指导。建议从哪里开始以及如何继续审查。
管理拉取请求的最佳实践
如果您是仓库维护者，请采取以下步骤来管理和标准化贡献者在您的仓库中创建的拉取请求。
使用拉取请求模板
拉取请求模板允许您自定义和标准化在有人在您的仓库中创建拉取请求时希望包含的信息。当您将拉取请求模板添加到您的仓库时，项目贡献者将在拉取请求正文中自动看到模板的内容。有关更多信息，请参阅“为您的仓库创建拉取请求模板”。
您可以使用拉取请求模板来标准化仓库的审查流程。例如，您可以通过在模板中添加任务列表，包含您希望作者在合并其拉取请求之前完成的任务列表。有关更多信息，请参阅“关于任务列表”。
您可以请求贡献者在其拉取请求正文中包含问题引用，以便合并拉取请求将自动关闭该问题。有关更多信息，请参阅“将拉取请求链接到问题”。
定义代码所有者
您可能希望确保特定人员始终审查对仓库中某些代码或文件的更改。例如，您可能希望团队中的技术作家始终审查 docs 目录中的更改。
您可以为存储库中代码或文件的责任人定义个人或团队，作为代码所有者。当有人打开修改其拥有文件的拉取请求时，系统会自动请求代码所有者进行审查。您可以为特定类型的文件或目录以及存储库中的不同分支定义代码所有者。有关更多信息，请参阅“关于代码所有者”。
使用受保护分支
您可以使用受保护分支来防止将拉取请求合并到重要分支（例如 main）中，直到满足某些条件。例如，您可以要求通过 CI 测试或批准审查。有关更多信息，请参阅“关于受保护分支”。
使用推送规则集
使用推送规则集，您可以根据文件扩展名、文件路径长度、文件和文件夹路径以及文件大小来阻止对私有或内部存储库及其整个 fork 网络的推送。
推送规则不需要任何分支目标，因为它们适用于对存储库的每次推送。
推送规则集允许您
-
限制文件路径：防止推送包含指定文件路径更改的提交。
您可以为此使用
fnmatch语法。例如，针对test/demo/**/*的限制会阻止对test/demo/目录中任何文件或文件夹的任何推送。针对test/docs/pushrules.md的限制会阻止专门对test/docs/目录中的pushrules.md文件进行推送。有关更多信息，请参阅“创建存储库的规则集”。 -
限制文件路径长度：防止推送包含超过指定字符限制的文件路径的提交。
-
限制文件扩展名：防止推送包含具有指定文件扩展名的文件的提交。
-
限制文件大小：防止推送超过指定文件大小限制的提交。
关于 fork 存储库的推送规则集
推送规则适用于存储库的整个 fork 网络，确保对存储库的每个入口点都受到保护。例如，如果您 fork 一个启用了推送规则集的存储库，则相同的推送规则集也将应用于您的 fork 存储库。
对于 fork 存储库，唯一具有推送规则绕过权限的人员是根存储库中具有绕过权限的人员。
有关更多信息，请参阅“关于规则集”。
使用自动化工具审查代码样式
在存储库的拉取请求中使用自动化工具（例如 linter）来保持一致的样式并使代码更易于理解。使用自动化工具来捕获诸如错别字或样式之类的小问题，可以让审阅者有更多时间专注于拉取请求的实质内容。
例如，您可以使用 GitHub Actions 设置代码 linter，这些 linter 可以在拉取请求中作为持续集成 (CI) 工作流的一部分运行。有关更多信息，请参阅“关于使用 GitHub Actions 进行持续集成”。