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 来讲也是需要的。