共计 1701 个字符，预计需要花费 5 分钟才能阅读完成。
本文作者：极狐 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 文件中指定的用户都不能推送指定文件或门路的更改，除非他们被特地容许。您不用限度开发人员间接推送到受爱护的分支。相同，您能够限度推送到某些须要代码所有者审核的文件。
当所有者设置为群组时的人数管制
当设置群组为代码所有人时，能够通过设置所有符合条件的用户的要求审批数目来实现人数管制。配置形式参考：
图示：群组责任人的人数管制
正文完
