拉取请求最佳实践

创建拉取请求的最佳实践

创建拉取请求时，请遵循一些最佳实践，以使评审过程更加顺畅。有关创建拉取请求的信息，请参阅“创建拉取请求”。

编写小型 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) 工作流程的一部分运行。有关更多信息，请参阅“关于持续集成”。