如何使用代码所有者实现代码“责任田”？

代码所有者 (PREMIUM ALL)

使用代码所有者功能来定义谁拥有项目代码库特定部分的专业知识。 定义仓库中文件和目录的所有者后，您可以方便地：

• **要求所有者批准更改。**将受保护的分支与代码所有者结合起来，要求专家在合并到受保护的分支之前批准合并请求。
• **识别所有者。**代码所有者名称显示在他们拥有的文件和目录上：

将代码所有者与合并请求批准规则（可选或必需）结合使用，可以构建灵活的批准工作流程：

• 使用代码所有者来确保质量。定义对存款中的特定路径具有领域专业知识的用户。
• 使用批准规则来定义与仓库中特定文件路径不对应的专业领域。批准规则有助于将合并请求创建者引导至正确的审核者团队，例如前端开发人员或安全团队。

例如：

类型	名称	范围	说明
批准规则	UX	所有文件	用户体验 (UX) 团队成员评审项目中所有更改的用户体验。
批准规则	Security	所有文件	安全团队成员评审所有更改是否存在漏洞。
代码所有者批准规则	Frontend: Code Style	*.css文件	前端工程师检查 CSS 文件更改是否符合项目样式标准。
代码所有者批准规则	Backend: Code Review	*.rb文件	后端工程师评审 Ruby 文件的逻辑和代码风格。

查看文件或目录的代码所有者

查看文件或目录的代码所有者：

1. 在左侧边栏中，选择 搜索或转到 并找到您的项目。
2. 选择 代码 > 仓库。
3. 转到您要查看其代码所有者的文件或目录。
4. 可选。选择一个分支或标签。

极狐GitLab 在页面顶部显示代码所有者。

设置代码所有者

先决条件：

• 您必须能够推送到默认分支或创建合并请求。

1. 在你偏爱的位置创建一个 CODEOWNERS 文件。
2. 在文件中定义一些遵循代码所有者语法参考的规则。 建议：
   • 配置所有可用批准者批准规则。
   • 在受保护的分支上要求代码所有者批准。
3. 提交更改，并将它们推送到极狐GitLab。

CODEOWNERS 文件

CODEOWNERS 文件（没有扩展名）指定负责仓库中特定文件和目录的用户或共享群组。

每个仓库使用一个单独的 CODEOWNERS 文件。极狐GitLab 按此顺序检查仓库中的这些位置。使用找到的第一个 CODEOWNERS 文件，忽略所有其他文件：

1. 在根目录中：./CODEOWNERS。
2. 在 docs 目录中：./docs/CODEOWNERS。
3. 在 .gitlab目录中：./.gitlab/CODEOWNERS。

当用户或群组更改名称

当用户或群组修改其名称时，CODEOWNERS 不会自动更新，因此您必须编辑文件。

使用 SAML SSO 的组织可以设置用户名以防止用户更改用户名。

群组作为代码所有者

要将群组或子群组成员设置为代码所有者：

在 CODEOWNERS 文件中，输入符合下列模式的文本：

# All group members as Code Owners for a file
file.md @group-x

# All subgroup members as Code Owners for a file
file.md @group-x/subgroup-y

# All group and subgroup members as Code Owners for a file
file.md @group-x @group-x/subgroup-y

NOTE: 如果启用了全局 SAML 群组成员锁，您无法将群组或子群组成员设置为代码所有者。

群组继承和资格

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
    accTitle: Diagram of group inheritance
    accDescr: If a subgroup owns a project, the parent group inherits ownership.
    A[Parent group X] -->|owns| B[Project A]
    A -->|contains| C[Subgroup Y]
    C -->|owns| D[Project B]
    A-. inherits ownership .-> D

在示例中：

• 父组 X (group-x) 拥有 项目 A。
• 父组 X 也包含子组，子组 Y (group-x/subgroup-y)。
• 子组 Y 拥有 项目 B。

符合条件的代码所有者是：

• 项目 A：仅限 群组 X 的成员，因为 项目 A 不属于 子组 Y。
• 项目 B：群组 X 和 子组 Y 的成员。

邀请子群组加入父群组中的项目

你可以邀请子群组 Y 加入到 项目 A 中，以便它们的成员也成为代码所有者。

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph LR
    accTitle: Diagram of subgroup inheritance
    accDescr: Inviting a subgroup directly to a project affects whether their approvals can be made required.
    A[Parent group X] -->|owns| B[Project A]
    A -->|also contains| C[Subgroup Y]
    C -.->D{Invite Subgroup Y<br/>to Project A?} -.->|yes| E[Members of Subgroup Y<br/>can submit Approvals]
    D{Invite Subgroup Y<br/>to Project A?} -.->|no| F[Members of Subgroup Y<br />cannot submit Approvals]
    E -.->|Add Subgroup Y<br/> as Code Owner to Project A| I[Approvals can be<br/>required] -.-> B
    F -.-> |Add Subgroup Y<br/> as Code Owners to Project A| J[Approvals can only<br/>be optional] -.-> B

如果你不邀请 子群组 Y 加入 项目 A，但将它们设置为代码所有者，它们的批准成为可选的。

邀请子群组加入父群组

邀请 子群组 Y 到 项目 A 的父群组中是不支持的。要将 子群组 Y 设置为代码所有者，请直接邀请该群组到项目本身。

NOTE: 对于要求批准的情况，代码所有者群组必须有直接成员(而不是继承成员)在项目中。批准只能是可选的，只有继承成员的群组。代码所有者群组成员也必须是直接成员，而不是从任何父级群组继承成员。

为更具体定义的文件或目录定义特定的所有者

当一个文件或目录与 CODEOWNERS 文件中的多个条目匹配时，将使用来自最后一个匹配该文件或目录的样式的用户。当您以合理的方式对条目进行排序时，这使您能够为更具体定义的文件或目录定义特定的所有者。

例如，在以下 CODEOWNERS 文件中：

# This line would match the file terms.md
*.md @doc-team

# This line would also match the file terms.md
terms.md @legal-team

terms.md 的代码所有者是 @legal-team。

通过将代码所有者设置到不同的节来组织代码所有者

changes how GitLab evaluates your Code Owners file: 在代码所有者中，部分 是文件中的命名区域，它们总是被分析和强制执行。直到您定义了一个部分，极狐GitLab 会将您的整个代码所有者文件视为一个部分。添加更多部分来更改如何评估您的代码所有者文件:

• 极狐GitLab 处理没有 section 的条目，包括在第一个部分之前定义的规则。
• 每个部分强制执行它们。
• 每个部分只匹配文件路径的一个模式。
• 在每个部分中，极狐GitLab 使用文件路径或目录的最后一个模式匹配每个 section。

比如，在使用 section 的 CODEOWNERS 文件中，让我们看看 README 文件的所有权：

* @admin

[README Owners]
README.md @user1 @user2
internal/README.md @user4

[README other owners]
README.md @user3

• 根 目录 README.md 的代码所有者是:
  • @admin，从未命名的 section。
  • @user1 和 @user2，从 [README Owners]。
  • @user3，从 [README other owners]。
• internal/README.md 的代码所有者是:
  • @admin，从未命名的 section。
  • @user4，从 [README Owners]。
  • @user3，从 [README other owners]。 (在 [README Owners] 中的两个条目匹配此文件名，但只保留最后一个节中的条目。)

要在 CODEOWNERS 文件中添加一个 section，请在方括号中输入 section 名称，然后输入文件或目录，以及用户、群组或子群组：

[README Owners]
README.md @user1 @user2
internal/README.md @user2

为 section 设置默认所有者

• 引入于极狐GitLab 15.11，使用名为 codeowners_default_owners 的功能标志。默认禁用。
• 在极狐GitLab 15.11 中 GA。功能标志 codeowners_default_owners 被移除。

如果 section 中的多个文件路径拥有相同的所有权，则为此 section 定义默认的代码所有者。此 section 中的所有路径都继承此默认设置，除非您在特定行上覆盖 section 的默认设置。

当没有为文件路径指定所有者时，使用默认的所有者。在文件路径旁边定义的特定所有者会覆盖默认所有者。

比如：

[Documentation] @docs-team
docs/
README.md

[Database] @database-team @agarcia
model/db/
config/db/database-setup.md @docs-team

在此示例中：

• @docs-team 拥有 Documentation section 中的所有项。
• @database-team 和 @agarcia 拥有 Database section 中的所有项，除了 config/db/database-setup.md，它有一个覆盖，将它分配给 @docs-team。

当在 section 中的条目不覆盖没有 section 的条目时，将此行为与一起使用常规条目和 section时相比较。

一起使用默认的所有者和可选的 section

为了将默认所有者和可选的 section 一起使用并要求审核，将默认所有者放在最后：

[Documentation][2] @docs-team
docs/
README.md

^[Database] @database-team
model/db/
config/db/database-setup.md @docs-team

一起使用常规条目和 section

如果你为 某一 section 之外的 某个路径设置了默认的代码所有者，那么他们的批准是必须的。 这些条目不会被 section 覆盖。 没有 section 的条目会被当作是另一个未命名的 section 来处理：

# Required for all files
* @general-approvers

[Documentation] @docs-team
docs/
README.md
*.txt

[Database] @database-team
model/db/
config/db/database-setup.md @docs-team

在此示例中：

• @general-approvers 拥有所有项，没有覆盖。
• @docs-team 拥有所有 Documentation section 中的项。
• @database-team 拥有所有 Database section 中的项，除了 config/db/database-setup.md，它有一个覆盖，将它分配给 @docs-team。
• 修改 model/db/CHANGELOG.txt 的合并请求需要来自 @general-approvers、@docs-team 和 @database-team 的三个批准。

当一个 section 中的特定条目会覆盖该章节的默认设置时，将这种行为与你仅使用 section的默认所有者时的情况进行比较。

重名的 section

如果多个 section 有相同的名称，它们会被合并。此外，section 标题不区分大小写。

[Documentation]
ee/docs/    @docs
docs/       @docs

[Database]
README.md  @database
model/db/   @database

[DOCUMENTATION]
README.md  @docs

这些代码会在 Documentation section 标头中出现三个条目，在 Database section 出现两个条目。 Documentation 和 DOCUMENTATION section 中的条目会使用第一个 section 中的大小写进行合并。

使代码所有者 section 可选

你可以在代码所有者文件中指定可选的部分。可选部分允许你为你的代码基础设定责任人，但不要求来自这些责任人的批准。这种方法为你的项目中的部分提供了更松散的政策，但不需要严格的审查。

要想将条目 section 作为可选的，请在 section 名称前添加 ^ 字符。

在此示例中，[Go] section 是可选的:

[Documentation]
*.md @root

[Ruby]
*.rb @root

^[Go]
*.go @root

如果文件中有重复的 section，且一个是可选的，另一个不是，那么这个 section 就是必须的。

CODEOWNERS 文件中的可选 section 仅在使用合并请求提交变更时是可选的。如果变更被直接提交到受保护分支上，则仍需要来自代码所有者的批准，即使 section 标记为可选的。

要要多个代码所有者审批

• 引入于极狐GitLab 15.9。

你可以在合并请求中要求多个代码所有者审批。将 section 名称和所需的人数添加到方括号中，例如 [2] 或 [3]。这就要求 n 个来自该 section 的代码所有者审批。 有效的 n 值是 ≥ 1。 [1] 是可选的，因为它是默认值。无效的 n 值将被视为 1。

设置多个来自代码所有者的审批：

1. 在左侧栏中选择 搜索或前往 并找到您的项目。
2. 选择 设置 > 仓库。
3. 扩展 受保护的分支。
4. 在默认分支旁边，打开 代码所有者审批 的切换。
5. 编辑 CODEOWNERS 文件以添加多个审批。

比如，要要求两个来自 [Documentation] section 的审批：

[Documentation][2]
*.md @tech-writer-team

[Ruby]
*.rb @dev-team

审核区域中的 Documentation 代码所有者 section 显示需要两个审批。

允许推送

允许推送 的用户可以选择从他们的变更上创建合并请求，或直接推送变更到分支。如果用户跳过合并请求流程，保护分支的功能和合并请求中的代码所有者审批也会被跳过。

比权限经常授予给关联到自动化的内部用户(内部用户) 和发布工具。

所有来自 *没有*允许推送 权限的用户必须经过合并请求。

相关主题

• 语法参考

极狐GitLab 技术支持

如果您使用过程中中遇到任何问题，您可以在极狐GitLab 官方论坛上发帖求助，您也可以直接扫描下方二维码咨询专业人员：