了解 codeowners
Source: Dev.to
什么是 CODEOWNERS 文件？
CODEOWNERS 文件是 GitHub 仓库中的一个特殊文件，用于自动定义对仓库中某些目录、文件或特定模式负责的个人或团队。
当一个 Pull Request 修改了受 CODEOWNERS 规则覆盖的代码时，指定的所有者会自动被添加为该 Pull Request 的必需审阅者。
📍 位置
要让 GitHub 识别此文件，必须将其放在以下位置之一：
.github/CODEOWNERS # 推荐位置
CODEOWNERS # 仓库根目录
docs/CODEOWNERS注意：
.github/CODEOWNERS的位置更受青睐，因为它将仓库的配置文件集中管理。
⚙️ 语法与工作原理
基本结构
每一行包含一个路径模式，后面跟一个或多个所有者（用空格分隔）。
# CODEOWNERS 示例文件
# 1. 仓库中所有代码，默认
* @octocat @github/support
# 2. 根目录下的 .md 文件
*.md @docs-team
# 3. 目录 'src/frontend/' 及其所有内容
src/frontend/ @frontend-lead
# 4. 特定文件
config/database.yml @backend-admin
# 5. 为子目录覆盖所有权
src/backend/users/ @user-management-team所有者类型
- 个人用户： 使用 GitHub 账号句柄，例如
@octocat。 - 团队： 使用 GitHub 团队语法，例如
@organization/team-name。推荐使用团队，因为当团队成员变动时，所有权管理更简便。
优先级规则
文件自上而下处理；对特定路径最后匹配到的模式才会生效。
- 较不具体： 先出现的规则或使用宽泛模式的规则。
- 更具体： 最后出现的规则，使用更具体的路径，会覆盖之前的规则。
优先级示例：
# CODEOWNERS
# 第 10 行（较不具体）：
src/models/* @data-team
# 第 50 行（更具体）：覆盖第 10 行的规则
src/models/user.js @auth-squad在此示例中，修改 src/models/user.js 的 Pull Request 只会要求 @auth-squad 审核，@data-team 将被忽略。
🛡️ 与受保护分支的集成
CODEOWNERS 的真正威力在于与 GitHub 的 分支保护规则 结合使用。保护某个分支（例如 main 或 master）时，可以启用 “Require review from Code Owners”（要求代码所有者审阅）的选项。
CODEOWNERS 工作流程
- 创建 Pull Request： 开发者提交 PR，修改了
src/billing/service.go和src/docs/README.md等文件。 - 自动分配： GitHub 分析 PR：
src/billing/service.go与src/billing/* @billing-team匹配。src/docs/README.md与docs/*.md @documentation-team匹配。
- 必需审阅者： GitHub 自动将
@billing-team和@documentation-team添加为必需审阅者。 - 合并： 在每个所有者团队至少有一名成员批准之前，PR 无法合并。
💡 必备最佳实践
1. 使用团队，而非个人
将所有权分配给团队（@org/team-name）而不是个人用户（@user-handle），可以确保：
- 当某人休假或离职时，审阅流程不会中断。
- 所有权和知识在功能组内部得到更好分布。
2. 定义回退规则（默认所有者）
始终包含一条宽泛的规则，例如：
# 对未明确分配的所有内容使用默认所有者
* @organization/core-team这可以确保没有任何更改会被遗漏审阅，为遗漏的文件或路径提供安全层。
3. 保持文件更新
CODEOWNERS 文件应反映团队和代码的当前结构。项目重构或团队变动时，需要同步更新此文件。理想情况下，对该文件的更改应由架构师或技术负责人审阅。
4. 对目录使用具体规则
避免使用过于宽泛的匹配规则。使用斜杠（/）指明整个目录及其内容的所有权。
# 错误：仅匹配目录根部的文件，不包括子目录
src/backend/*.js @js-team
# 正确：匹配 'src/backend/' 目录下的所有文件和子目录
src/backend/ @backend-team⚠️ CODEOWNERS 的关键限制：基于路径的僵硬性
GitHub 原生的 CODEOWNERS 系统仅能回答一个问题：“修改了哪个文件？” 这导致了三个重要挑战：
-
缺乏合并上下文
CODEOWNERS对目标分支（合并的目标分支）视而不见。无法仅在 PR 目标为main时要求架构师审阅，也无法在只针对staging的hotfix时放宽规则。换句话说，无法基于目标分支来分配审阅者。 -
无法实现交叉条件（AND/OR）
系统不能组合多个条件。规则只能在路径匹配时生效，这阻止了以下逻辑的实现：- AND： “仅当 PR 修改了
src/auth/下的文件 且 打上security-review标签时，才分配安全团队。” - OR： “分配给 L…*（原文截断）”。
- AND： “仅当 PR 修改了