提交更改

GitHub Pull Request有丰富的功能集，可以帮助用户改进协作流程。

创建Pull Request草稿

创建Pull Request的最佳时间是什么时候？每个人的观点可能都不同，作者认为：越早越好！理想情况下，用户可以在开始处理某项工作时创建Pull Request。这样，团队只需要查看打开的Pull Request，就可以知道每个人都在做什么。但是如果过早地开启Pull Request，审阅者就不知道何时给出反馈。这就是Pull Request草稿的好处，用户可以尽早创建Pull Request，每个人都知道工作仍在进行中，审阅者还没有得到通知，但是用户仍然可以在注释中提到相关人员，以便尽早获得代码反馈。

创建Pull Request时，可以直接在草稿状态下创建（见图3-8）。

Pull Request草稿会被明确标记为Draft，并有自己的图标（参见图3-9）。用户还可以使用draft:true或draft:false作为搜索参数来过滤搜索中的Pull Request。

如果Pull Request已处于审阅状态，用户仍然可以通过单击Reviewers|Still in progress?|Convert to draft继续编辑。

如果Pull Request已准备好接受审阅，只需要单击“Ready for review”（见图3-10）。

Pull Request草稿是一个很好的功能，可以以透明的方式变更存储库内容以尽早进行团队协作。

代码所有者

当存储库中的某些文件发生更改时，代码所有者（code owner）可以自动将审阅者添加到Pull Request中。这个特性还可以用于跨团队协作，并且还可以在早期开发阶段添加许可，而不需要在发布阶段来要求许可。假设开发者在存储库中有设置基础设施的代码，可以使用code owner的功能要求协作团队中的某个人进行审阅。假设有可以定义应用程序外观的文件，每次修改它们可能需要获得设计团队的批准。code owner不仅仅是给予许可，它们还可用于在跨团队的协作社区中传播知识。

code owner可以是团队或个人。他们需要拥有写入权限才能成为code owner。如果Pull Request不是草稿状态，则code owner将被添加为审阅者。

要定义code owner，用户需要在存储库的根目录下的docs/或者.github/目录中创建一个名为CODEOWNERS的文件。该文件的语法很简单，如下所示：

●使用@username或@org/team-name定义代码所有者，还可以使用用户的电子邮件地址。

●使用模式匹配文件以指派代码所有者。顺序很重要：最后匹配的模式优先。

●使用#表示注释，！表示对模式求反，[]表示定义字符范围。

下面是code owner文件的示例：

关于code owner的详细信息，请参阅链接：https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-code-owners。

code owner是一个可以跨越团队共享知识的很好的方式，并将发布阶段的许可权限转变到变更发生时的早期许可。

审阅设置

在合并Pull Request之前，用户可以要求指定数量的审批。这在可应用于多个分支的branch protection rule上设置。在Settings|Branches|Add rule下可以创建分支保护规则。在规则中，用户可以设置合并前所需的审阅数量，选择是否要在更改代码时取消审批，以及强制执行代码所有者的审批（参见图3-11）。

有关分支保护的更多信息，请参见https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#about-branch-protection-rules。第11章将更详细地介绍这一内容。

设置Pull Request审阅

如果代码已准备好接受审阅，用户可以手动添加所需数目的审阅者。GitHub会根据修改代码的作者推荐审阅者（见图3-12）。用户只需要单击“Request”，也可以手动搜索人员以执行审阅：

也可以让GitHub自动为团队分配审阅者。在Settings|Code review assignment下可以进行相关配置。用户可以选择自动分配的审阅者数量，并选择以下两种算法之一：

●Round robin：选择到目前为止收到最少请求的审阅者作为此次的审阅者。

●Load balance：根据每个成员的审阅请求总数（考虑未完成的审阅）选择审阅者。

可以将某些成员排除在审阅之外，也可以选择在指定审阅者时不通知整个团队。请参见图3-13以了解如何为团队配置代码审阅任务。

自动合并

Pull Request中最令人喜欢的特性之一是自动合并（auto-merge）。这允许用户在处理小的更改时提高速度，特别是在启用了持续部署（Continuous Deployment，CD）的情况下。如果满足所有策略，自动合并将自动合并更改。如果已经完成了更改，则可以启用自动合并来处理其他更改。如果Pull Request通过了一定数量的许可并且通过了所有的自动检查，则Pull Request将自动合并并部署到生产环境中。