提议更改

GitHub 拉取请求拥有丰富的功能集，可以帮助您改善协作流程。

草稿拉取请求

什么时候创建拉取请求是最合适的？对此可以有不同的看法，但我认为：越早越好！理想情况下，在开始处理某项工作时就创建拉取请求。这样，团队成员只需查看打开的拉取请求，就能知道每个人正在做什么。但是，如果拉取请求创建得太早，审阅者可能不知道何时给出反馈。这时，草稿拉取请求就派上用场了。您可以早早创建拉取请求，但大家知道工作仍在进行中，审阅者不会收到通知，但您仍然可以在评论中提到其他人，以便提前获得代码反馈。

创建拉取请求时，您可以直接将其设置为 草稿状态（见图3.8）：

Figure 1. 图 3.8 – 创建一个草稿状态的拉取请求

草稿拉取请求会清楚地标记为 “草稿”，并且有自己独特的图标（见图3.9）。您还可以通过在搜索时使用 draft:true 或 draft:false 作为搜索参数来筛选拉取请求：

Figure 2. 图3.9 – 草稿拉取请求标有独特符号

如果您的拉取请求已经处于审阅状态，您仍然可以随时通过点击 "Reviewers | Still in progress? | Convert to draft" 来将状态更改为草稿。

如果您的拉取请求已经准备好接受审阅，只需点击 "Ready for review"（见图3.10）即可：

Figure 3. 图3.10 – 取消拉取请求的草稿状态

草稿拉取请求是一个很好的功能，可以让团队在透明的环境下早早地就变更进行协作。

代码所有者

代码所有者（Code Owners）是一个很好的功能，可以在您的仓库中的某些文件发生变化时，自动为拉取请求添加审阅者。这个功能也可以跨团队协作，或者在开发的早期阶段就要求批准，而不是等到发布管道时才要求批准。假设您的仓库中定义了作为代码的基础设施，您可以使用代码所有者要求来自共享运维团队的人员进行审阅；或者，您有定义应用外观和风格的文件，每次修改这些文件时，您可能希望得到设计团队的批准。代码所有者不仅仅是用于批准，它们还可以用于跨团队边界在实践社区中传播知识。

代码所有者可以是团队或个人。他们需要拥有写权限才能成为代码所有者。当拉取请求从草稿状态移出时，代码所有者会自动成为审阅者。

要定义代码所有者，您需要在仓库的根目录、docs/ 文件夹或 .github/ 文件夹中创建一个名为 CODEOWNERS 的文件。文件的语法很简单，如下所示： - 使用 @username 或 @org/team-name 来定义代码所有者。您也可以使用用户的电子邮件地址。 - 使用模式来匹配文件，以指定代码所有者。顺序很重要：最后匹配的模式会优先。 - 使用 # 来添加注释，! 来否定一个模式，[ ] 来定义字符范围。

以下是一个代码所有者文件的示例：

# The global owner is the default for the entire repository
* @org/team1

# The design team is owner of all .css files
*.css @org/design-team

# The admin is owner of all files in all subfolders of the
# folder IaC in the root of the repository
/IaC/ @admin

# User1 is the owner of all files in the folder docs or
# Docs – but not of files in subfolders of docs!
/[Dd]ocs/* @user1

有关代码所有者的更多详细信息，请参阅以下页面：关于代码所有者。

代码所有者是跨团队边界获取共享知识的绝佳方式，并且可以将审批流程从发布管道中的变更审核板转移到更早的阶段，在变更发生时就进行审批。

必需的审查

您可以在合并拉取请求之前要求一定数量的审批。这是在分支保护规则中设置的，该规则可以应用于多个分支之一。您可以在设置中创建分支保护规则，路径为：Settings | Branches | Add rule。在规则中，您可以设置合并前所需的审核次数，选择是否在代码变更时取消先前的审批，并强制执行代码所有者的审批（见图 3.11）：

Figure 4. 图 3.11 – 为特定分支设置所需的审批

有关分支保护的更多信息，请参见：关于受保护分支。我将在第 7 章 “基于主干的开发” 中详细讨论这个话题。

请求拉取请求审查

如果您的代码已经准备好进行审核，您可以手动添加所需数量的审核者。GitHub 会根据您所更改的代码作者提供审核者的建议（见图 3.12）。您可以直接点击 “请求” 或手动搜索需要执行审核的人：

Figure 5. 图 3.12 – 建议的审核者

您还可以让 GitHub 自动分配审核者给您的团队。您可以在设置中为每个团队配置这一功能，路径为：Settings | Code review assignment。您可以选择自动分配的审核者数量，并选择以下两种算法之一：

循环分配（Round robin）：根据谁最近接受的请求最少来选择审核者。
负载均衡（Load balance）：根据每个成员的总审核请求数量（考虑未完成的审核）来选择审核者。

您可以排除某些成员不进行审核，也可以选择在分配审核者时不通知整个团队。请参见图 3.13，了解如何为您的团队配置代码审核分配：

Figure 6. 图 3.13 – 管理团队的代码审核分配

自动合并

我最喜欢的拉取请求功能之一是自动合并（auto-merge）。它可以帮助你在处理小的更改时提高工作效率，特别是在启用持续部署（CD）的情况下。自动合并会在所有策略都符合的情况下自动合并你的更改。如果你已经完成了更改，你可以启用自动合并并开始处理其他更改。如果拉取请求获得了所需的批准且所有自动检查都通过，拉取请求将会自动合并并部署到生产环境。