gerrit access control

Special and magic references

https://vlab.noaa.gov/code-review/Documentation/access-control.html#references

The reference namespaces used in git are generally two, one for branches and one for tags:

• refs/heads/*

• refs/tags/*

However, every reference under refs/* is really available, and in Gerrit this opportunity for giving other refs a special meaning is used. In Gerrit they are sometimes used as magic/virtual references that give the push to Gerrit a special meaning.

 

refs/for/<branch ref>

Most prominent is the refs/for/<branch ref> reference which is the reference upon which we build the code review intercept before submitting a commit to the branch it’s uploaded to.

Examples of typical roles in a project

https://gerrit.int.com/Documentation/access-control.html#example_roles

Below follows a set of typical roles on a server and which access rights these roles typically should be granted. You may see them as general guidelines for a typical way to set up your project on a brand new Gerrit instance.

Contributor

This is the typical user on a public server. They are able to read your project and upload new changes to it. They are able to give feedback on other changes as well, but are unable to block or approve any changes.

Suggested access rights to grant:

• Read on 'refs/heads/\*'

• Push to 'refs/for/refs/heads/*'

• Code-Review with range '-1' to '+1' for 'refs/heads/*'

If it’s desired to have the possibility to upload temporarily hidden changes there’s a specific permission for that. This enables someone to add specific reviewers for early feedback before making the change publicly visible.

Developer

This is the typical core developer on a public server. They are able to read the project, upload changes to a branch. They are allowed to push merge commits to merge branches together. Also, they are allowed to forge author identity, thus handling commits belonging to others than themselves, effectively allowing them to transfer commits between different branches.

They are furthermore able to code review and verify commits, and eventually submit them. If you have an automated CI system that builds all uploaded patch sets you might want to skip the verification rights for the developer and let the CI system do that exclusively.

Suggested access rights to grant:

• Read on 'refs/heads/\*'

• Push to 'refs/for/refs/heads/*'

• Push merge commit to 'refs/for/refs/heads/*'

• Forge Author Identity to 'refs/heads/*'

• Label: Code-Review with range '-2' to '+2' for 'refs/heads/*'

• Label: Verified with range '-1' to '+1' for 'refs/heads/*'

• Submit on 'refs/heads/*'

If the project is small or the developers are seasoned it might make sense to give them the freedom to push commits directly to a branch.

Optional access rights to grant:

• Push to 'refs/heads/*'

• Push merge commit to 'refs/heads/*'

Project Owner Guide

https://gerrit-documentation.storage.googleapis.com/Documentation/2.12.3/intro-project-owner.html#project-owner

This is a Gerrit guide that is dedicated to project owners. It explains the many possibilities that Gerrit provides to customize the workflows for a project.

What is a project owner?

Being project owner means that you own a project in Gerrit. Technically this is expressed by having the Owner access right on refs/* on that project. As project owner you have the permission to edit the access control list and the project settings of the project. It also means that you should get familiar with these settings so that you can adapt them to the needs of your project.

Being project owner means being responsible for the administration of a project. This requires having a deeper knowledge of Gerrit than the average user. Normally per team there should be 2 to 3 persons, who have a certain level of Git/Gerrit knowledge, assigned as project owners. It normally doesn’t make sense that everyone in a team is project owner. For normal team members it is sufficient to be committer or contributor.

Here is the flow of gerrit code review.

https://haiyanghaiyang.gitbooks.io/gerrit-user-manual/content/ti-jiao-dai-ma-ping-shen/code-review-flow.html

• Engineer commit change list in local git and push to gerrit for review.

  $git add file

  $git commit -m "message"

  $git push origin HEAD:refs/for/<branch name>

  Engineer should add reviewers one by one to review the CL.

• When code in review, engineer can amend the CL and push that into gerrit again as patch set 2, 3 etc.

  $git add file

  $git commit --amend

  $git push origin HEAD:refs/for/<branch name>

https://blog.7v1.net/development/gerrit-workflow.html

Gerrit 中采用了虚拟分支来实现一些特性，如：push 到 refs/for/* 分支视为提交一次 Patchset，refs/changes/10/1010/1 用于下载已经提交的 Patchset 代码。一般情况下，如果只围绕这 master 分支开发的话，可以不需要任何其他分支。

非分支开发

1. 使用远端的 master 分支代码覆盖本地代码：git fetch origin master && git checkout FETCH_HEAD；

2. 在此基础上进行开发，开发完成后提交 Patchset：git push origin HEAD:refs/for/master；

3. Review 未通过，被打回重新修改：git fetch origin refs/changes/<change-id> && git checkout FETCH_HEAD；

4. 修改完成后，再次提交 Patchset：git add -u && git commit --amend --no-edit && git push origin HEAD:refs/for/master；

5. Review 通过，合并到 master 分支；

6. 开发下一个特性，重复上述步骤；

但是，如果碰到很多的大型的特性，一个 Change 无法完成，那就不得不启用分支开发了，所以分支模型对于 Gerrit Workflow 来讲也是需要的。

 二次评审

https://blog.7v1.net/development/gerrit-code-review/gerrit-code-review.html

2.2. 二次评审

有时候你的代码中可能包含某些错误，别人帮你 review 出来了，这时就需要进行二次评审。 二次评审很常见，过程也很简单，基本步骤如下^[8]：

1. 保存或清理你之前的工作，保持本地仓库干净，如 git stash 等命令。

2. 切换到被评审后需要修改的版本。

   1. 方法一：点击 Change 详情页右上角「Download」下拉箭头拷贝下载命令执行。

   2. 方法二：使用命令手动下载。

      1. 找到需要二次评审的 Change Number，如：一个 Change 的 URL 为 https://git.7v1.net/251126，那么它的 Change Number 就是 251126，下称「CHANGE」。

      2. 确定要基于哪个 Patchset 进行修改，可在 https://git.7v1.net 界面中拿到（Change 详情页的右上角，「Patch Sets」下拉箭头），下面称「PATCHSET」。

         

      3. 执行下面的命令（或者执行 alias 命令 git fp {CHANGE} {PATCHSET}），将要修改的 Patchset 拉到本地。

         git fetch origin refs/changes/{CHANGE 的最后两位}/{CHANGE}/{PATCHSET}
         # 如 251126 号 Change 第 2 个 Patchset
         # git fetch origin refs/changes/26/251126/2
         git checkout FETCH_HEAD

         • 请不要盲目照抄上述命令，「{}」的内容请按照规则进行替换。

3. 根据评审建议进行修改，构建并测试你的代码。

4. 完成后，执行命令 git commit --amend --no-edit（或者执行 alias 命令 git cin）进行提交。

   • 如果是本次提交的 commit message 需要修改，请使用 git commit --amend 命令提交。

5. 执行下面的命令（或者 alias 命令 git rv），将你的修改提交到 Gerrit Code Review 系统中。邀请你的评审者进行二次评审。

   git push origin HEAD:refs/for/master

   Tip	二次评审不需要再次指定 reviewer 等信息。