代码所有者
使用代码所有者功能来定义谁拥有项目代码库特定部分的专业知识。 定义仓库中文件和目录的所有者后，您可以方便地：
- 要求所有者批准更改。将受保护的分支与代码所有者结合起来，要求专家在合并到受保护的分支之前批准合并请求。
-
识别所有者。代码所有者名称显示在他们拥有的文件和目录上：
将代码所有者与合并请求批准规则（可选或必需）结合使用，可以构建灵活的批准工作流程：
- 使用代码所有者来确保质量。定义对存款中的特定路径具有领域专业知识的用户。
- 使用批准规则来定义与仓库中特定文件路径不对应的专业领域。批准规则有助于将合并请求创建者引导至正确的审核者团队，例如前端开发人员或安全团队。
例如：
| 类型 | 名称 | 范围 | 说明 |
|---|---|---|---|
| 批准规则 | UX | 所有文件 | 用户体验 (UX) 团队成员评审项目中所有更改的用户体验。 |
| 批准规则 | Security | 所有文件 | 安全团队成员评审所有更改是否存在漏洞。 |
| 代码所有者批准规则 | Frontend: Code Style |
*.css 文件 |
前端工程师检查 CSS 文件更改是否符合项目样式标准。 |
| 代码所有者批准规则 | Backend: Code Review |
*.rb 文件 |
后端工程师评审 Ruby 文件的逻辑和代码风格。 |
查看文件或目录的代码所有者
查看文件或目录的代码所有者：
- 在左侧边栏中，选择 搜索或转到 并找到您的项目。
- 选择 代码 > 仓库。
- 转到您要查看其代码所有者的文件或目录。
- 可选。选择一个分支或标签。
极狐GitLab 在页面顶部显示代码所有者。
设置代码所有者
先决条件：
- 您必须能够推送到默认分支或创建合并请求。
CODEOWNERS 文件
CODEOWNERS 文件（没有扩展名）指定负责仓库中特定文件和目录的用户或共享群组。
每个仓库使用一个单独的 CODEOWNERS 文件。极狐GitLab 按此顺序检查仓库中的这些位置。使用找到的第一个 CODEOWNERS 文件，忽略所有其他文件：
- 在根目录中：
./CODEOWNERS。 - 在
docs目录中：./docs/CODEOWNERS。 - 在
.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
群组继承和资格
在示例中：
-
父组 X (
group-x) 拥有 项目 A。 -
父组 X 也包含子组，子组 Y (
group-x/subgroup-y)。 - 子组 Y 拥有 项目 B。
符合条件的代码所有者是：
- 项目 A：仅限 群组 X 的成员，因为 项目 A 不属于 子组 Y。
- 项目 B：群组 X 和 子组 Y 的成员。
邀请子群组加入父群组中的项目
你可以邀请 子群组 Y 加入到 项目 A 中，以便它们的成员也成为代码所有者。
如果你不邀请 子群组 Y 加入 项目 A，但将它们设置为代码所有者，它们的批准成为可选的。
邀请子群组加入父群组
邀请 子群组 Y 到 项目 A 的父群组中是不支持的。要将 子群组 Y 设置为代码所有者，请直接邀请该群组到项目本身。
为更具体定义的文件或目录定义特定的所有者
当一个文件或目录与 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：
为 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拥有Documentationsection 中的所有项。 -
@database-team和@agarcia拥有Databasesection 中的所有项，除了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拥有所有Documentationsection 中的项。 -
@database-team拥有所有Databasesection 中的项，除了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，且一个是可选的，另一个不是，那么这个 section 就是必须的。
CODEOWNERS 文件中的可选 section 仅在使用合并请求提交变更时是可选的。如果变更被直接提交到受保护分支上，则仍需要来自代码所有者的批准，即使 section 标记为可选的。
要要多个代码所有者审批
- 引入于极狐GitLab 15.9。
你可以在合并请求中要求多个代码所有者审批。将 section 名称和所需的人数添加到方括号中，例如 [2] 或 [3]。这就要求 n 个来自该 section 的代码所有者审批。
有效的 n 值是 ≥ 1。 [1] 是可选的，因为它是默认值。无效的 n 值将被视为 1。
设置多个来自代码所有者的审批：
- 在左侧栏中选择 搜索或前往 并找到您的项目。
- 选择 设置 > 仓库。
- 扩展 受保护的分支。
- 在默认分支旁边，打开 代码所有者审批 的切换。
- 编辑
CODEOWNERS文件以添加多个审批。
比如，要要求两个来自 [Documentation] section 的审批：
[Documentation][2]
*.md @tech-writer-team
[Ruby]
*.rb @dev-team
审核区域中的 Documentation 代码所有者 section 显示需要两个审批。
允许推送
允许推送 的用户可以选择从他们的变更上创建合并请求，或直接推送变更到分支。如果用户跳过合并请求流程，保护分支的功能和合并请求中的代码所有者审批也会被跳过。
比权限经常授予给关联到自动化的内部用户(内部用户) 和发布工具。
所有来自 没有 允许推送 权限的用户必须经过合并请求。
相关主题
极狐GitLab 技术支持
如果您使用过程中中遇到任何问题，您可以在极狐GitLab 官方论坛上发帖求助，您也可以直接扫描下方二维码咨询专业人员：
