细粒度的代码权限怎么做？极狐GitLab 代码所有者来帮忙
本文作者：极狐GitLab 资深解决方案架构师 尹学峰
如果基于固定的评审规则每次都是那几个人，当仓库很大的时候，各个模块（文件夹）责任人不同，其他人并不太懂。所以当修改不同的模块时候，基于固定规则就太死板了。而且容易造成「评审行为」的流于形式，因为固定的人可能根本看不懂实际MR变更涉及到的模块代码。最终就导致，评审者直接点了approve按钮，这非常不合适。
简述
极狐GitLab的代码所有者解决了以下场景的痛点：
-
代码审查：确保特定代码区域的变更得到相关所有者的审查，提高代码质量。即在合并请求过程中，基于变更文件，动态指定相关代码所有者参与合并请求审批过程，确保代码安全与稳定。
-
负责人分配：为关键代码区域指定所有者，明确责任划分，有助于项目管理。
-
团队协作：提高团队成员之间的协作效率，减少沟通成本。
图示：承包鱼塘好
详述
代码所有者
代码所有者定义
代码所有者定义谁开发和维护功能，并拥有仓库中生成的文件或目录。
- 当您浏览目录时，您定义为代码所有者的用户会显示在 UI 中。
图示：文件浏览时的所有者会显示在页面上
- 您可以设置合并请求，以便在合并前必须得到代码所有者的批准。
图示：Code Owner示例
- 您可以保护分支并仅允许代码所有者批准对分支的更改。
使用代码所有者、核准人以及批准规则，构建灵活的批准工作流程：
-
使用 代码所有者，定义对仓库中的特定路径具有领域专业知识的用户。
-
使用 核准人 和 批准规则 来定义专业领域（例如安全团队），这些领域不限于仓库中的特定文件路径。
-
核准人定义用户。
-
批准规则定义这些用户何时可以批准工作，以及是否需要他们的批准。
例如：
| 类型 | 名称 | 范围 | 说明 |
|---|---|---|---|
| 批准规则 | UX | 所有文件 | 用户体验 (UX) 团队成员评审项目中所有更改的用户体验。 |
| 批准规则 | Security | 所有文件 | 安全团队成员评审所有更改是否存在漏洞。 |
| 代码所有者批准规则 | Frontend: Code Style | *.css 文件 | 前端工程师检查 CSS 文件更改是否符合项目样式标准。 |
| 代码所有者批准规则 | Backend: Code Review | *.rb 文件 | 后端工程师评审 Ruby 文件的逻辑和代码风格。 |
创建一个 CODEOWNERS 文件，指定负责仓库中特定文件和目录的用户或共享群组。每个仓库都可以有一个CODEOWNERS 文件。创建步骤：
- 选择要指定代码所有者的位置：
-
在仓库的根目录中
-
在
.gitlab/目录中 -
在
docs/目录中
-
在那个位置，创建一个名为 CODEOWNERS 的文件。
-
在文件中，输入遵循以下模式之一的文本：
# Code Owners for a file
filename @username1 @username2
# Code Owners for a directory
directoryname/ @username1 @username2
# All group members as Code Owners for a file
filename @groupname
# All group members as Code Owners for a directory
directoryname/ @groupname
受保护分支的代码所有者控制
对于受保护的分支，您可以要求至少获得代码所有者的一项批准。
要保护新分支并启用代码所有者的批准：
-
转到您的项目并选择 设置 > 仓库。
-
展开 受保护的分支。
-
从 分支 下拉菜单中，选择要保护的分支。
-
从 允许推送 和 允许合并 列表中，选择您想要的设置。
-
打开 需要代码所有者的批准 开关。
-
选择 保护。
要在已受保护的分支上启用代码所有者的批准：
-
转到您的项目并选择 设置 > 仓库。
-
展开 受保护的分支。
-
在受保护分支列表中，打开分支旁边的 需要代码所有者批准 开关。
启用后，这些分支的所有合并请求都需要每个匹配规则的代码所有者批准，然后才能合并。 此外，如果匹配规则，则拒绝直接推送到受保护分支。
任何未在 CODEOWNERS 文件中指定的用户都不能推送指定文件或路径的更改，除非他们被特别允许。 您不必限制开发人员直接推送到受保护的分支。相反，您可以限制推送到某些需要代码所有者审核的文件。
当所有者设置为群组时的人数控制
当设置群组为代码所有人时，可以通过设置所有符合条件的用户的要求审批数目来实现人数控制。配置方式参考：
图示：群组责任人的人数控制
