Gerrit简单介绍

参考：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代码，都会包含这笔提交。