理想情况下的 Code Review,评审人员是最熟悉这块代码的同学,但是实际上 Author 并不一定知道谁应该 Review 自己的改动。
CodeOwner 机制是维护一个文件,指明哪些路径下的哪些文件被谁 Own 应该谁去 Review,当 Push 更改中包含这些文件时,就会将 Own 这些代码的人自动加到评审人中。
我们使用了一个 CODEOWNERS 文件来记录代码库中各模块或文件的负责人,该文件应位于分支的根目录下。
当一次评审发起,且代码库启用了 CodeOwner 审核,那么系统会在评审目标分支的根目录下,寻找 CODEOWNERS 文件,并从其中读取相关设置。当文件对应规则仅设置了一位 CodeOwner,则必须此用户评审;当文件与CodeOwner 出现了 1:N 的情况时,例如一个文件对应了A、B、C三位 Owner,此时只要有一位 CodeOwner 审核通过即可。
此外,评审创建时或评审分支更新后,系统会自动检测需要参与评审的 CodeOwner,并把他们自动加入审核人列表中。
当启用 CodeOwner 模式时,合并请求至少需要 1 人评审通过,即如果没有匹配到任何Owner,需要至少 1 人评审进行兜底保护。
对于修改的每个文件,会按最精细的规则去匹配,一个文件只会匹配一个规则。如 CODEOWNERS 文件中定义了如下 4 个路径:
** @user1
aa/** @user2
aa/mm/** @user3
bb/** @user4
此时,评审中有一个文件是 f.txt,它会匹配到最精细的规则,即**@user1 规则;
如果评审中有一个文件是 aa/f.txt ,则会匹配到aa/**@user2 规则;
同样的,如果评审中有一个文件是 aa/mm/f.txt ,则会匹配到aa/mm/**@user3 规则;
CODEOWNERS 文件中,对于路径的定义采用了 Glob 的语法(即 Linux 中 find 命令、Git中 .gitignore 文件定义文件的规则时采用的语法)。
路径规则追加空格后,采用 @username 的形式定义相关 Owner,username 需使用对应 Owner 已验证并绑定的主邮箱。主邮箱可在个人设置①-个人信息中的②处查看。
示例如下:
# 注释行,以下为配置正文,每一行代表一个配置。
# 一个路径规则后边,需要有一个或多个Owner
# 用户 A@example.com,B@example.com 作为所有文件的CodeOwner
** @A@example.com @B@example.com
# 用户 C@example.com 作为所有java文件的CodeOwner
**.java @C@example.com
# 用户 D@example.com、E@example.com 作为force-api目录下文件的CodeOwner
force-api/** @D@example.com @E@example.com
# 用户 F@example.com 作为force-base/src/main/java目录下文件的CodeOwner
force-base/src/main/java/** @F@example.com