参考：Gerrit官方文档

Gerrit是基于Git的版本控制系统的web版代码评审工具。

What is Gerrit

代码审查对不同的人意味着不同的东西。对一些人来说，这是一次与设计师或一个团队一行一行过代码的正式会议。对其他人来说，就是在提交代码之前，让别人浏览一下代码。

Gerrit的目的就是为代码提交到代码库之前提供一个评审的轻量级框架。代码提交到Gerrit上之后，实际上并没有真正被项目接受，直到被评审通过。

Gerrit在代码被正式接受之前，为代码检查设置了一个staging area，在这里可以对该提交进行修改、讨论、增加注释……

分布式进行、不需要面对面操作。

Where does Gerrit fit in?

任何一个团队都有某种类型的*代码库。Git理论上可以在没有*代码库的情况下工作，但实际上他有一个*存储库。这是项目中实际存在的权威性副本。每个人或编译服务器都可以从*的认证代码服务器下代码或推代码。

Gerrit也是部署在*代码仓库的地方，只是增加了新的部分，一个staging area。每个人仍然可以从代码库中下载代码，但是并没有直接推送回去。修改暂时推送到Gerrit提供的staging area，只有最终通过评审，才能提交到*代码库中。

同时Gerrit具有强大的访问权限控制，用户可以被赋予绕过代码评审的权限直接推送代码。Gerrit也可以仅用作代码存储，不进行代码评审。

The Life and Times of a Change

了解Gerrit的工作原理的最简单的方法就是熟悉一个change的生命周期。我们假设，Gerrit 服务器（gerrithost）使用http的8080端口、ssh的29418端口，并且所有的开发都在RecipeBook这个代码库的master分支上进行。

Cloning the Repository

首先，使用git clone的方法，从gerrithost上获取我们要修改的源代码

$ git clone ssh://gerrithost:29418/RecipeBook.git RecipeBook
Cloning into RecipeBook...

然后我们就可以在本地进行实际的修改和提交。Gerrit通过hook在commit message中加了一个Change-Id，这样就可以关联这笔提交的不同版本。

Creating the Review

当本地进行了修改并且commit之后，就可以把代码push到Gerrit上进行review了。

$ <work>
$ git commit
[master 9651f22] Change to a proper, yeast based pizza dough.
 1 files changed, 3 insertions(+), 2 deletions(-)
$ git push origin HEAD:refs/for/master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 542 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: New Changes:
remote:   http://gerrithost:8080/68
remote:
To ssh://gerrithost:29418/RecipeBook.git
 * [new branch]      HEAD -> refs/for/master

唯一的不同点就是refs/for/master分支，我们是主要是通过这个分支，对提交到master分支的代码就行review。

git push之后的返回值，有个http的链接，这个了解就是我们提交review代码的地址。

这就是我们的代码评审页面，这里可以看到提交change的差异、添加评论说明做了什么和为什么这么做。

评审人可以设置多种搜索条件，来查询他们关注的change；并且可以对gerrit 的project设置一定条件的监听（watch），这样当有他关注的修改出现时，会有邮件提醒。

Reviewing the Change

当评审人（Reviewer）来到评审页面，当页面中有如下字样时，便可以进行评审。

* Need Verified
* Need Code-Review

在代码被accept前，Gerrit有两条检查的工作流要求。“Code-Review”表示一个人觉得这个修改满足项目要求；“Verifying”表示这个修改通过了编译、单元测试……。“Verifying”通常由自动化构建服务器实现，比如jenkins的gerrit trigger插件就可以进行verify并打分。

“Verified”和“Code-Review”在Gerrit中需要不同的权限，所以任务需要分开。

作为Reviewer，我们可以通过双击要注释的行（或单击行号）来添加inline comments。此外，还可以在标题中双击任何地方（不仅仅是“patch set”），或者单击行号列标题中的图标来添加文件注释。一旦发布这些注释，所有人都可以看到，允许进行更改的讨论。

因为评审代码（查看、评论、修改～）会花费很长时间，所以Gerrit提供了一些快捷键，来提高效率。

当我们查看完代码之后，我们需要添加我们的评审意见。点击页面上的“Review”按钮，就可以添加我们评审意见并打分。

Reviewer的评审一件决定了这个change的走向。“+1”和“-1”只是一种一件，“+2”和“-2”表示这个change是被accept还是block。要想这个change被accept，必须有一个“+2”而不能有“-2”。数值不会累加。

不论选择了哪种标签，一旦点击了“Publish Comments”按钮，所有的信息都能被用户看到。

如果Change没有被accept，那么开发就需要重做（rework）了。

Reworking the Change

如果在最初push之前，我们设置了“Change-Id commit-msg hook”，那么重做（rework）就比较简单了。如果两个change有同样的Change-Id，重做后的change，就可以直接push到那一个上面。E.g.

$ <checkout first commit>
$ <rework>
$ git commit --amend
$ git push origin HEAD:refs/for/master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 546 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Processing changes: updated: 1, done
remote:
remote: Updated Changes:
remote:   http://gerrithost:8080/68
remote:
To ssh://gerrithost:29418/RecipeBook.git
 * [new branch]      HEAD -> refs/for/master

push之后我们得到的输出和上次不同，是“Updated Changes”，它告诉我们现有的review已经更新了。

打开回传的http链接，查看已经更新的change。

这时，这个change下面就多了一个patch set。

Trying out the Change

有时代码需要手动验证，或者reviewer需要检查代码实际的工作方式。这时我们需要把change download到本地来进行验证。gerrit 提供了download command的插件，在gerrit的页面中也有download的命令可以直接复制。

$ git fetch http://gerrithost:8080/p/RecipeBook refs/changes/68/68/2
From http://gerrithost:8080/p/RecipeBook
 * branch            refs/changes/68/68/2 -> FETCH_HEAD
$ git checkout FETCH_HEAD
Note: checking out 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at d5dacdb... Change to a proper, yeast based pizza dough.

说明：

• 前一个68，是change的id mod 100的值，为了减少git库内指定目录的文件数量
• 第二个68，这个change的真实id，就是屏幕上的返回值。
• 2，就是patch set的id，因为第一条被拒了，所以要的是第2个。

Manually Verifying the Change

”Verifier“可以和”Reviewer“是同一个或不同人，有权限verify的人，可以点开”Review“按钮进行验证打分。

"verify"没有+2或-2选项，所以我们只能对提交的change进行+1或-1的操作。

Submitting the Change

当change被verify+1和code review +2了，这时页面上会出现"submit"按钮，点击这个按钮，就可以把这个change正式提交到代码库中。这时，再添加新的comment，不会修改打分；而如果上传了新的patch，打分就会重置。

和“verify”、“code review”一样，“submit”的权限也是也是掌握在一组人手中的。

当代码被submit之后，任何人从代码库中git clone代码，都会包含这笔提交。