转：Gerrit 学习

转载：http://www.scmeye.com/thread-1665-1-1.html

入门
Gerrit简介
Gerrit是一个建立在Git版本控制系统之上，基于Web的代码审查工具，但如果你已经阅读过该指南，那么你可能已经知道了。介绍的目的就是然你回答这个问题，Gerrit是适合我的工具吗？它是否适合我团队的工作流程。
Gerrit是什么?
我假设，如果你正在读这篇文章，并且你已经相信一般的代码评审的好处，但需要一些技术支持是它容易。代码评审，对不同的人意味着不同的事情。对于某些人，是一个一台投影机和整个团队通过一行行代码的正式会议。对于另外的人，是在代码提交之前的浏览代码。
Gerrit提供一个重量轻框架，每次提交被接受合入代码库之前，对进行代码评审。变更上传到Gerrit，但实际上并没有成为该项目的一部分，直到他们已经评审和接受。在许多方面，这是简单的工具，以支持提交的补丁被应用到代码库之前，被该项目的成员评审过标准的开源过程。然而Gerrit进了一步使项目所有提交以确保真正接受之前所有的变更都被检查变的简单。因为Gerrit对于如闭源的商业开发的情况，所有用户都是被信任提交者同样是有用的。无论哪种方式，它仍然是可取的代码评审，以提高代码的质量和可维护性。毕竟，如果只有一个人看过的代码，当人离开后它可能是有点难来维护。
Gerri首先是一个临时存储区域，变更成为一个代码库的一部分之前，可以被检查。它也是这一评审进程的推动者，获取变更的笔记和备注来对变更进行讨论。对于不能面对面交流的分布式团队，这是特别有用的。即使位于同底协作小组有评审工具，作为一个选择也是有益的，因为每次评审对于评审人员是很方便的。允许开发人员创建评审和解释的变更，当他们的想法还很新鲜的时候。如果没有这样的工具，他们要么需要打断别人来评审代码，或者切换内容来解释变更，这时他们已经转移到下一个任务了。
这也创造持久的谈话记录，用来回答不可避免的“我知道我们修改的原因”问题。

Gerrit的适用范围
任何多成员团队都具有某种形式的中心代码库（或他们应该有）。Git可以理论上没有这样的中心库，但在实践中通常有一个中心库。这服务器充当了实际项目的权威副本。中心服务器是允许大家获取和上传代码，一般是构建服务器和其他类似工具获取源。
特性1：中心代码库
Gerrit部署在这个中心库上，并增加了一个额外的概念，存储待定的变更。所有人仍然从权威的库中获取代码，但是推送到待定变更位置来代替直接推送到权威库中。当变更被评审和接受后，才允许提交到权威库中作为项目被接受的一部分。
特性2：代替中心库
像任何库的托管解决方案一样，Gerrit具有强大的访问控制模型。用户甚至可以被授予权限直接推入中心库，完全绕过代码评审。Gerrit甚至可以没有代码评审，只用于管理库和访问控制。但一般只是更简单和更安全通过评审过程，甚至允许用户直接推送。

创建评审
一旦你完成修改并提交到本地，这就是时候推送修改到Gerrit上去评审啦。推送到Gerrit服务器就完成了。因为我们直接从Gerrit克隆到本地仓库的源没有重新定义remote地址。
$ <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/master1
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:2 
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分支。每一个分支都跟踪有一个神奇推送的refs/for/<branch_name>，来创建评审。你会注意这个命令的输出，正是我们要推送到的Gerrit服务器的HTTP连接地址。我们正是在这个web地址上评审这次提交。我们打开连接看看能看到什么。

特性3：Gerrit代码评审屏幕
Gerrit代码评审的屏幕上就会有人来评审变更。这里看不到太多，你可以看看你的变更的差异，添加一些注释说明你做了什么，为什么，你甚至可以添加一组人评审变更。
评审者可以通过各种方式指导需要评审的变更。Gerrit拥有强悍搜索功能，项目负责人（或其他任何人）找到需要评审的变更。用户还可以通过搜索表达式来设定Gerrit项目设置关注，这样Gerrit会通知他们匹配的变化。

评审变更
评审者的生活始于评审屏幕上的代码。可以有多种方式到达这里，但由于某些原因，他们已经决定将评审这一变更。特别值得注意的是此屏幕上的两个“Need”的行：
* Need Verified
* Need Code-Review
Gerrit默认的工作流程在变更被接受前有两个检查。Code-Review是人的看代码，以确保它符合项目的方针，意图等。Verify检查的是实际代码的编译、通过单元测试等。Verify通常是由一个自动构建的服务器完成，而不是一个人。有一个Gerrit Trigger Jenkins Plugin插件对每一次上传的变更自动构建，并更新相应的verify分数。重要注意的是，Gerrit中Code-Review和Verify的权限是不同，允许这些任务分开。例如：自动的过程可以有Verify权限，但是没有Code-Review权限。因为我们是代码评审者，需要评审代码。要做到这一点，我们可以在Gerrit Web界面上选择合适的方式查看代码，或者完整的文件或者两边差异的试图。在下面的图例中，我们选择了两边差异的试图方式。在这些试图中，你可以通过双击要备注的行上添加备注（或单击行号）。一旦发布这些备注所有人都能查看，允许对变更讨论。

特性4:两边补丁评审
代码评审者最终花了很多时间浏览这些画面，查看和评论这些变更。为了使这个操作尽可能高效，Gerrit有大多数快捷键操作(甚至有些操作只能通过热键访问)。在任何时候，你可以打’？’键关来查看键盘快捷键。
特性5:Gerrit热键帮助
一旦我们检查完变更，我们需要完成提交评审。我们可以在我们初始进入的变更屏幕上点击Review 按钮。这使我们能够输入一个代码评审标签和消息。

特性6:评审变更
评审人员选择的标签，决定了下一步会发生什么。’+1’和’-1’只是一个意见，但是’+2’和’-2’是允许或阻塞变更。为了变更被接受，它必须有最少一个’+2’并没有’-2’。 虽然这些数值，但是他们不能计算;两个+1并不等同于+2。不管什么标签被选中，一旦” Publish Comments ”按钮被点击，封面信息和文件的任何意见所有都用户可见。在这种情况下，变更不被接受，创作者需要返工。因此，让我们的切换角色到我们开始创造者。

变更返工
只要我们设置了Change-Id commit-msg钩子，在我们上传的变化之前，重新工作是很容易。所有我们需要上传返工的变更，推送另一个具有相同Change-ID提交。由于钩子再我们最初的提交中添加了Change-ID，我们可以简单的检出和修改提交。然后以之前创建评审时同样的方式推送到Gerrit上，如下。
$ <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)
To ssh://gerrithost:29418/RecipeBook.git
* [new branch]      HEAD -> refs/for/master
请注意这一次输出略有不同。我们并没有得到一个新的评审记录，因为我们追加到了已存在的评审记录上了。返工提交上传完成，我们可以回到Gerrit界面查看我们的变更。

特性7:评审返工提交
如果你仔细观察，你会发现这个变更有两个patch set，一个最初提交和返工提交。而不是重复我们的操作，假设这次补丁被代码评审人员给了+2。
尝试变更 
Gerrit的默认工作流有两种签收机制，Code Review和Verify。Verify是指检查实际工作的变更。这通常会检查代码编译，单元测试合格及类似检查。项目真的可以决定，他们要在这里做的多或少。这也许没什么价值，这仅仅是Gerrit的默认工作流，Verify检查实际上可以被删除或增加其他验证。正如在Code Review部分中提到，Verify通常是一个自动化过程，使用Gerrit Trigger Jenkins Plugin插件或类似。但有时代码需要手动Verify，或者评审人员需要检查一些实际工作内容或工作原理。这些都需要有人将变更取到他们的开发环境中。Gerrit让这个过程变容易，通过显示每一个变化作为一个git分支。因此，所有的评论人员需要做的是，从Gerrit获取和检出该分支，他们将拥有变化。
我们不需要把这想的太难，如果你看过前面的Gerrit Code Review屏幕屏幕截图，你会发现一个” download ”命令。我们获取变更需要做的就是,是复制粘贴此命令，并运行它在我们的Gerrit检出。
$ 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.
这么简单，现在我们的工作副本已经有这个变更了，一起玩。你可能感兴趣 refspec数字意味着什么。
•        第一个68是变更号模100的编号。这个初始数的唯一原因以减少在git仓库内的任何给定的目录的文件数量。
•        第二个68是变更的完整编号。你会发这个编号在Gerrit评审屏幕的URL中。
•        2是本次变更内的patch-set数。在这个例子中，我们上传了一些修正，所以我们希望是第二个补丁集而不是最初被拒绝的。

手动的Verify变更
为简单起见，我们只是要手动Verify变更。Verify的人可以与Code review的人相同也可以是完全不同的人，这真的取决于项目的规模和工作内容。如果你已经有Verify权限，然后当您单击Gerrit Web界面的Review 按钮，你会要求验证得分。
特性8:Verify变更
跟Code review不同Verify检验没有+2和-2，只有成功或者失败，必须有一个+1才允许提交(并且不能有-1)。
Submit变更'
你可能已经注意到，在验证的屏幕截图中，有两个按钮提交比分，” Publish Comments”和” Publish and Submit”。 ” Publish and Submit”按钮始终是可见的，但只满足提交条件才可以生效(例如已经Verify和Code Review过了)。所以这是很方便来张贴评审评分，以及通过点击一个按钮提交变更。如果你这时候只选择发布意见，然后分数将被保存，但变更尚未被代码库接受。在这种情况下，住屏幕上会有一个“Submit Patch Set X”按钮。正如Code Review和Verify，可以通过不同的用户做不同的操作，第三个提交操作可以通过另一组用户控制。
激活Publish and Submit 或者Submit Patch Set X 按钮，将变更合入到主库中，成为项目被接受的一部分。获取git仓库后，这个人会接受这种变化作为主分支的一部分。Fetch git仓库后，会接受变更作为主分支的一部分。

•        默认工作流
Android开源项目（AOSP）使用Gerrit是基于Web的代码审查工具。下面的图片是一个流程图，详细说明一个补丁被写入后会发生什么情况。虽然它可能会有点复杂，下面的步骤大部分是在Web应用程序上进行的。
对于如何安装和使用Gerrit和git的完整说明，请参阅提交补丁页面。