理想情况下的 Code Review,评审人员是最熟悉这块代码的同学,但是实际上 Author 并不一定知道谁应该 Review 自己的改动。

CodeOwner 机制是维护一个文件,指明哪些路径下的哪些文件被谁 Own 应该谁去 Review,当 Push 更改中包含这些文件时,就会将 Own 这些代码的人自动加到评审人中。

我们使用了一个 CODEOWNERS 文件来记录代码库中各模块或文件的负责人,该文件应位于分支的根目录下。当一次评审发起,且代码库启用了 CodeOwner 审核,那么系统会在评审目标分支的根目录下,寻找 CODEOWNERS 文件,并从其中读取相关设置。当文件与CodeOwner 出现了 1:N 的情况时,例如一个文件对应了A、B、C三位 Owner,此时只要有一位 CodeOwner 审核通过即可。此外,评审创建时或评审分支更新后,系统会自动检测需要参与评审的 CodeOwner,并把他们自动加入审核人列表中。

当启用 CodeOwner 模式时,合并请求至少需要 1 人评审通过。

CODEOWNERS 文件中,对于路径的定义采用了 Glob 的语法(即 Linux 中 find 命令、Git中 .gitignore 文件定义文件的规则时采用的语法)。

路径规则追加空格后,采用 @username 的形式定义相关 Owner,username 需使用对应 Owner 已验证并绑定的主邮箱。主邮箱可在个人设置-个人信息中的①处查看。

示例如下:

# 注释行,以下为配置正文,每一行代表一个配置。
# 一个路径规则后边,需要有一个或多个Owner

# 用户 Tiger@alibaba.com,Dragon@alibaba.com 作为所有文件的CodeOwner
** @Tiger@alibaba.com @Dragon@alibaba.com

# 用户 Alan@alibaba.com 作为所有java文件的CodeOwner
**.java @Alan@alibaba.com

# 用户 Ben@alibaba.com、Carl@alibaba.com 作为force-api目录下文件的CodeOwner
force-api/** @Ben@alibaba.com @Carl@alibaba.com

# 用户 Mike@alibaba.com 作为force-base/src/main/java目录下文件的CodeOwner
force-base/src/main/java/** @Mike@alibaba.com