摘要

  • CODEOWNERS 是按分支和路径匹配的责任路由配置；对于修改受管代码的非草稿拉取请求，GitHub 可以自动向相应所有者请求审查。
  • 实际匹配取决于基准分支中的文件、文件位置优先级、最后一个匹配模式、变更路径以及所有者的有效权限。今天看到的文件不能替代昨天的事件证据。
  • 可靠的审查凭证应分开保存适用配置、变更集、请求事件、审查回应和其他合并控制的观察结果；这是一种编辑性的证据方法，而非 GitHub 的产品要求。

配置说的是应当路由到哪里

“代码所有者已经审过”听起来像一句完整的结论，实际上至少遗漏了五个问题：拉取请求的基准分支是什么？它改了哪些路径？哪个匹配模式最终生效？被指定的账户或团队当时是否具备资格？请求发出后，是否有一份针对该变更集的审查回应？如果没有把这些问题拆开，静态配置就会被误写成已经发生的行动。

GitHub 对 CODEOWNERS 的定义很克制：它用于定义对仓库代码负责的个人或团队。非草稿拉取请求改动了有所有者的代码时，GitHub 会自动请求相应所有者审查；草稿状态不会自动发出该请求，直到请求被标记为可审查。自动请求的价值在于分派专业注意力，不在于替代审查本身。通知被路由，不等于判断已经形成。

这一规则还严格依赖分支。每个 CODEOWNERS 文件只为一个分支分配所有者，审查请求使用拉取请求基准分支上的版本。从派生仓库向上游提交时，使用的是上游基准分支的文件。因此，同一补丁指向 main 和指向维护分支，可能得到不同的责任映射。来源分支里新加的文件、或默认分支上后来显示的文件，都不能证明当时生效的映射。

文件位置也会改变结果。GitHub 按 .github/、仓库根目录、docs/ 的顺序查找，并使用找到的第一个文件。超过三兆字节的文件不会被加载；此时所有者信息不会显示，相应的审查请求也不会发出。配置存在于仓库中，与配置在某次事件中实际参与了路由，是两件不同的事。

最后一个匹配模式会改写责任面

模式文件很容易给人“规则叠加”的直觉，GitHub 的语义却是选择性的：最后一个匹配模式优先。一个覆盖全部路径的 * 规则，可能会被后面的 *.js 规则取代。多个所有者写在同一行时共同拥有该模式；把相同模式的所有者写在不同且都匹配的行中，后面的行则会取代前面的结果。若只引用通用规则，而不重建当时的路径和顺序，就可能把责任归给从未被请求的对象。

还有一些不能被忽略的条件。路径对大小写敏感；语法无效的一行会被跳过；不存在或权限不足的用户、团队不会被分配为所有者。这些事实并不说明任何特定仓库出了问题。它们说明一份政策文本有自己的有效条件，不能仅凭截图变成事件结论。

GitHub 还建议为 CODEOWNERS 文件本身指定所有者。这一点揭示了更深的治理要求：负责分配责任的规则，也必须让其修改路径可见。否则，一个仓库能声明谁负责应用代码，却无法解释谁能改变这份声明。

审查、门禁与合并不是同一个记录

GitHub 把自动请求审查与“合并前必须获得代码所有者批准”明确分开，后者需要管理员或所有者另行配置。若一个模式有多个所有者，在该要求开启时，其中任一人的批准即可满足这一项。这说明 CODEOWNERS 文件并不会自动把每个名字变成合并否决权。

它也不会穷尽其他控制。ruleset 与分支保护可以同时适用；适用规则会聚合，若同一规则有不同版本，以限制更严的一项为准。拉取请求、批准数量、代码所有者审查、状态检查、部署成功、评论解决、合并方式和绕过权限，都是可以分别配置的面。GitHub 特别指出，即使所需审查都已批准，只要另一份指向同一头部提交的开放拉取请求仍有待处理或被拒绝的审查，该请求也可能无法合并。

批准仍然是一项重要事实：它表示审查者认为改动已准备好合并。但它的范围应被保留。它是对某个变更集的审查状态，而不是对所有规则、所有系统检查和所有后续行动的一张总收据。

建立“配置到审查”的凭证

对需要被追溯的重要主张，最小凭证应先记录拉取请求标识、基准与头部的提交或树引用，以及变更路径集合。随后保存基准分支上适用的 CODEOWNERS 文件位置和内容身份，而非只链接今天的页面；再列出匹配规则、解析出的所有者以及已知的资格缺口。

下一层才是事件：审查请求何时发出，谁以何种状态回应，回应覆盖哪个 diff 或提交。如果叙述延伸到合并准备状态，还应单独列出适用的保护规则或 ruleset、各项观察到的状态以及任何有记录的绕过。缺少某一环时，主张就应停在上一环。这不会创造新的 GitHub 权力；它只是避免把当前的路由政策叙述成过去事件的完整证据。

来源

  1. GitHub Docs — About code owners
  2. GitHub Docs — Pull request reviews
  3. GitHub Docs — About rulesets
  4. GitHub Docs — Available rules for rulesets