Code Owners
Code Owners
版本历史
- 在GitLab Starter 11.3 中 .
- 支持在 GitLab Starter 12.1 中添加的 .
在为项目做贡献时,通常很难找出谁应该审查或批准合并请求. 此外,如果您对特定文件或代码块有疑问,可能很难知道从谁那里找到答案.
GitLab 代码所有者是一项功能,用于定义谁拥有存储库中的特定文件或路径,从而允许其他用户了解谁对每个文件或路径负责.
代码所有者允许使用版本控制的单个真实文件源,该文件概述了拥有存储库中某些文件或路径的确切 GitLab 用户或组. 可以在合并请求批准过程中利用代码所有者,该过程可以简化为给定合并请求找到合适的审阅者和批准者的过程.
在大型组织或流行的开源项目中,如果您遇到的问题可能与代码审查或合并请求批准无关,则代码所有者还可以帮助您了解与谁联系.
您可以使用文件来指定负责存储库中某些文件的用户或共享组 .
您可以在三个位置选择并添加CODEOWNERS
文件:
- 到存储库的根目录
- 在
.gitlab/
目录中 - 在
docs/
目录中
当一个文件与CODEOWNERS
文件中的多个条目匹配时,与该文件匹配的上一个模式的用户将显示在给定文件的 Blob 页面上. 例如,您具有以下CODEOWNERS
文件:
将显示的用户为@user2
.
将”代码所有者”设置为项目后,可以将其配置为用于合并请求批准:
- As .
- 根据需要批准分支机构 .
注意 :为了批准合并请求,需要开发人员或更高 .
设置后,”代码所有者”将显示在合并请求小部件中:
尽管CODEOWNERS
文件除了可以用于合并请求 ,还可以用作合并请求批准的唯一驱动程序(不使用批准规则 ). 为此,请在上面指定的三个位置之一中创建文件,并将代码所有者设置为必需批准者. 使用代码所有者文件的语法来指定实际所有者和精细权限.
可以使用与.gitignore
文件中使用的相同类型的模式来指定文件,然后使用一个或多个用户的@username
或电子邮件或应作为文件所有者的一个或多个组的@name
进行指定. 必须将组添加为 ,否则它们将被忽略.
从GitLab 13.0开始,您现在可以将项目组层次结构中的组或子组指定为潜在的代码所有者.
例如,考虑给定项目的以下层次结构:
以下任何组都可以被指定为代码所有者:
@group/sub-group/sub-subgroup
此外,使用” 成员”工具邀请到项目的任何组也将被视为合格的代码所有者.
定义路径的顺序很重要:与给定路径匹配的最后一个模式将用于查找代码所有者.
以#
开头的行表示注释. 需要使用\#
对其进行转义,以寻址其名称以#
开头的文件.