Gerrit权限官方文档
https://gerrit.wikimedia.org/r/Documentation/access-control.html#system_groups
捡重点:
1. 成员组
Anonymous Users 成员组 是所有用户,对其的权限设置, 对所有用户都生效
2. Special references | 特殊命名空间
refs/changes/* : 存储所有patch 提交
refs/meta/config : 存储Gerrit仓库 即project的配置信息
refs/heads/* : 存储分支
refs/tags/* : 存储tag
refs/for/<branch ref> : 审核分支, 提交到这个命名空间, 就可以在Gerrit上看到,参与代码review
3. 权限继承原理:
先计算子仓, 再计算父仓, 权限根据情况覆盖(父仓block, 子仓不可重载, 父仓deny, 子仓可重载), 这种方式, 对于一些私有仓库很适用.
如果父仓allow成员组A, 子仓allow成员组B, B是A的子集, 则最终子仓的allow人员为A.
如果父仓deny, 子仓allow, 则最终子仓allow.
如果父仓block, 子仓allow, 则最终子仓block(无权限).
如果子仓不做权限设置,则自动继承父仓.
用在实际情况上, 如Gerrit上仓库对公司C所有成员开放, 但对于该公司的外包人员D只开放指定仓库E, 则可以在Gerrit All-Project上, refs/* 的read allow C | read deny Anonymous Users, 然后再在E上设置成 refs/* read allow即可. 则D登录Gerrit后, 仅能看到E仓库, 如果有其他仓库继承E, 且没有做read限制, 则也可以被看到.
如果权限没有被设置, 则默认是不允许的, 如refs/*下指定label+1的权限, 仅设置了成员组A allow, 成员组B 没有被设置, 则对于该仓库, 成员组B是不可以label+1的, 如果有其他仓库继承该仓, 该权限也会被继承,
对于仓库的访问权限,是通过read权限来控制, 如果read没有给权限,即deny或者block, 却给了review的权限, 那也是没有用的, 下载仓库会提示fatal: Could not read from remote repository. Gerrit上也看不到这个仓库
3.1 权限类别
拥有push权限也会同时具有push,abandon,restore
rebase: 默认change的作者和管理员
4. Global Capabilities | 全局能力配置
如果这个里面, 是全局能力配置, 赋予权限需慎重, 如果给了Create Project的allow权限, 则也会拥有创建分支, tags, reference的权限.
