什么是Gerrit？

　　Gerrit 是一个基于 web 的代码评审工具, 它基于 git 版本控制系统。Gerrit 旨在提供一个轻量级框架, 用于在代码入库之前对每个提交进行审阅。‎‎更改将上载到 Gerrit, 但实际上并不成为项目的一部分, 直到它们被审阅和接受。它是标准开源过程的一个简单工具来支持提交补丁程序, 然后由项目成员在应用到代码库之前进行评审。‎Gerrit 首先是一个临时区域, 在提交的代码成为代码库的一部分之前, 可以对其修改进行检查。‎‎

Gerrit适用场景？

　　任何具有多个成员的团队都有某种类型的中心源存储库 (或者应该这样做)。Git 可以理论上工作, 没有这样的中心位置, 但实际上通常有一个中央存储库。这是项目中权威内容的副本。这是每个人获取源代码或者推送的源库，, 通常是这里也集成了build服务器和其他一些工具。

figure 1. 通常的

　　Gerrit部署在中心库的位置并且添加了新的功能和作用。具体看下图。

figure 2.

Gerrit中一个change的生命周期：使用方法

1、克隆源码到本地

　　代码编辑后在本地进行提交，Gerrit没有参与这个阶段，只是标准的修改和git操作。。

2、创建一个review

　　一旦你在本地完成commit，就需要把他push到Gerrit，这样才能被review。这就需要git push到Gerrit server。

　　从下图中可以看到HEAD被推送到refs/for/master，这是master的的魔幻分支，用于创建review。对于每一个分支，Gerrit都会追踪一个魔幻分支refs/for/<branch_name>。在review视图你可以diff 你的change，也可以加入一些为什么你要这么做的注释，也可以添加一个reviewer的列表。

3、使用同一个change ID重新提交

　　经过一次upload会在commit中生成change ID，如果需要把重新修改的change提交到Gerrit，我们只需要在commit msg中加入上次使用的change ID。或者使用git commit --amend命令可以把这次commit的信息与上次的commit合并起来。注意remote返回的信息，显示是Update Changes，而上次是New Changes。如果你再仔细观察，你会在看到2个 patch set 关联到了一个change ID。更新可能是通过判断commit ID识别的，虽然change ID一样，但是git commit --amend会生成不同的commit ID。

If you look closely you’ll notice that there are now two patch sets associated with this change, the initial submission and the rework. Rather than repeating ourselves lets assume that this time around the patch is given a +2 score by the code reviewer.

4、下载和验证change

　　正如代码审查部分所述，验证通常是使用Gerrit Trigger Jenkins Plugin或类似程序的自动化过程。但是有时候需要手动验证代码，或者审阅者需要检查某些内容是否有效，或者它是如何工作的。 Gerrit通过将每个更改变为git分支来使这个过程变得简单。 所以所有的评论者需要做的是从Gerrit获取并签出该分支，他们将会有所改变。在review界面可以看到download command，我们所需要做的就是复制粘贴这个命令并在我们的Gerrit checkout中运行它。

遇到的问题

我最近工作遇到了如下问题，公司的开发环境架构是 repo（git）+ gerrit代码审查软件 + CI持续集成服务器，我同步代码到本地，第一次提交代码正常，第二次就有可能出现merge conflict的问题。问题原因在下面的注释里。

情况1

git commit 1　　//代码修改第一次完成，commit第一次，commit ID为1。

repo upload　　//第一次提交代码到gerrit服务器，正常。gerrit 生成review，change ID 1，下面关联了1个 patch set 1。

git commit 2　　//代码修改第二次完成，commit第二次，commit ID为2。

repo upload　　//第二次提交代码到gerrit，生成另个一review，change ID 2。其实注意观察这时，change ID会多出一个 patch set 2。

问题：

　　结果①：如果两次修改了相同文件的相同位置，就会出现merge conflict错误；

　　结果②：修改的内容不同，不会报错。

原因分析：

　　change ID 2是基于change ID 1的，因此可以看到它的review界面的dependencies下有change ID 1的链接。而且change ID 1的review界面needed by有change ID 2的链接，change ID 1和change ID 2的关系是merge合并的关系，因此如果对相同位置做了不同的修改，就会报merge conflict错误。注意这里第2次repo upload没有更新change ID 1的信息，因为两次的commit ID相同。

情况2

git commit 1　　//代码修改第一次完成，commit第一次，commit ID为1。

git commit 2　　//代码修改第二次完成，commit第二次，commit ID为2。

repo upload　　//有可能出现 merge conflict 问题

问题：

　　结果①：如果两次修改了相同文件的相同位置，就会出现merge conflict错误；

　　结果②：修改的内容不同，不会报错。

原因分析：

　　这种提交代码的方式，会一次产生两个change ID，也就是gerrit会根据commit ID的个数生成多个change ID。change ID的作用就是用来识别不同的 code review，那为什么gerrit会根据commit ID来进行生成changge ID呢？

　　试着回答一下，因为commit msg中包含了change ID的信息，Gerrit会首先查找现存的review中有没有一样的change ID并把把具有相同change ID的commit组成一个 patch set，正如下面的来自Gerrit官方文档描述的那样。

因此情况1与情况2的不同之处是

　　情况1会把change ID 1更新，并且生成patch set 2。

　　情况2一次生成两个 patch set ，没有更新change ID 1。

参考文章

Gerrit的官网总参考：https://gerrit.asterisk.org/Documentation/index.html#_tutorial

Gerrit的快速介绍：https://gerrit.asterisk.org/Documentation/intro-quick.html