Gerrit 代码审核全流程_gerrit 配置仓库需要评审

Gerrit，一种免费、开放源代码的代码审查软件，使用网页界面。利用网页浏览器，同一个团队的软件程序员，可以相互审阅彼此修改后的程序代码，决定是否能够提交，退回或者继续修改。它使用Git作为底层版本控制系统。它分支自Rietveld，作者为Google公司的Shawn Pearce，原先是为了管理Android计划而产生。

                                                                                                                             

一.拉取项目代码

参与项目的第一步就是在本地建立代码仓库，git clone之前有一些准备工作需要完成，否则后续会出问题。

以下步骤默认你下载安装好了git......

一般公司的项目代码平台都是需要开通账户，审核之后才能从Gerrit上拉取项目代码，这就涉及一个SSH加密鉴权过程，需要在git的设置中完善，如下：

git ssh configuration

找到C\用户\用户名（你的用户名）\.ssh文件

假如从来没有配置过ssh，图中的config文件不会存在，自己建一个就好，无后缀。

配置好的内容应该如下：

其中的参数例如 Host、HostName等就是你的个人账号和主机名，关键是第4、5行的Key的设置，一定要注意，很多失败就是因为这两行，当然了，有些人会把自己的用户名打错，那就没办法了......

除了config文件，gerrit的底层git是需要ssh公钥的，这个的生成，直接打开cmd，敲击以下命令：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

引号里的是你的账号，也就是邮箱。

之后就会生成rsa密钥文件，里面的内容可以直接打开读取，也可以通过git gui的help-show SSH key读取，如下：

git clone

万事俱备后，就可以从gerrit页面上复制git命令行，在本地clone代码了：

gerrit-BROWSE-Repository-你的项目

复制，回到本地，找一个你心怡的地方，鼠标右键Open git bash here，运行复制的命令行：

git clone "ssh://1111111@11.11.11.11:11111/Project/C111" && scp -p -P 29418 111111@11.11.11.11:hooks/commit-msg "11111/.git/hooks/"

代码下载完毕之后，记得切换分支：

git checkout yourbranch

你的本地代码会自动切换到你的分支下面，这里简单说一下分支branch，类似树枝生长，项目程序开发也是分型的，几个人负责不同的部分，主干代码Trunk中只会保留最核心的功能和最稳定的部件。你自己的branch假如没有别人参与的话，嗯造就完事，就是千万别往主干代码上push你没有经过别人确认过的代码，一定要找PL（Program Leader）审核之后再传到主干代码。

二.代码上传

写完了代码，得赶紧上传，不然延误了时间，可就要损失不少money，Gerrit就是一个审核平台，传上去让PL看看再说。

以下命令都是上传时会用到的，我按时间顺序排列好了：

git status

git status

用于查看当前你的修改和主干代码上的有何不同，假如有几个文件是修改过的，会显示出来，这几个文件应该就是你贡献的代码部分的所在了，为什么说应该呢？

因为现实中，你可能会误操作，动了别的模块的代码或是格式，这些修改都会显示在git status的结果中，所以，你要去看哪些是你正儿八经、深思熟虑后的修改，哪些是你的误操作，使用的命令就是下一节的git diff。

git diff

git diff FilePath\File

文件路径\文件名会在git status的结果中出现，鼠标选中直接Ctrl+Insert复制，然后Shift+Insert粘贴到git diff 之后，回车。

方向键↓查看下一行，我的建议是不要跳行，仔细一点，很多bug都是某一行修改的后果。

git add

确认无误之后，使用git add将代码转发到本地缓存区，这里只是暂存处理。

git add .

表示添加所有文件，假如没有修改过的文件，是不会进入缓存区的，git会在比对之后，将修改过的文件发到缓存区。

当然，有些文件你并不想添加，比如makefile文件，这个文件的更改会影响到别的模块，你只是在调试的时候改过几个参数。假如你只想添加特定的文件，那就使用：

git add FilePath/FileName

添加单个文件。

git commit

这一步十分关键，gerrit和git不一样的地方就在于一个叫做Change Id的设置，这个设置是需要在commit信息里注明的，否则无法完成commit，这是gerrit的一个格式要求。

git commit “Commission Informaiton”

commit之后，你会发现报错，类似这个：

深呼吸，这是正常的现象，因为你的Change Id没有设置，报错信息里会有一句提示，执行提示的命令：

gitdir=$(git rev-parse --git-dir); scp -p -P 29418 liyj@gerrit.ingageapp.com:hooks/commit-msg ${gitdir}/hooks/

我的建议是在-p和-P之间加一个-O，表示scp以ssh_config中的格式传输，这样稳妥一些。

之后你的每一次commit信息就会以Change Id结尾了，commit步骤才能完成。

注意，有的项目会要求头部添加redmine#number形式的抬头，使用

git commit --amend 在头部添加[redmin#1211]即可

抬头和结尾类似数据帧的头和尾，gerrit需要这些信息来确认commit的合法性

git push

commit之后就是push，注意，gerrit不能直接push到主干代码（理论和道德上不可以，但实际中可以），需要先提交给代码管理员审核，审核区域在HEAD -> refs/for/branch下，审核通过之后才会进行合入的操作。

git push origin HEAD:refs/for/xxxx

git commit --amend

push成功之后，你肯定会后悔，就像考试完交卷后的恍然大悟。

深呼吸，别急着难受，git是有后悔药的：

git commit --amend
git commit --amend --no-edit

再次完成代码修改，并且git add之后，执行以上命令，第一个会修改commit信息，第二个不修改直接提交。

三.Gerrit页面操作

指定审核人

上传完change之后，你会在主页看到自己的提交：

Outgoing review是你发起的change，需要别人审核的

Incoming review和Your turn 会显示需要你审核的change

Recently closed是已经结束了审核的change

点到你刚才发起的change中

在Reviewers中选择审核人，一般来说，凡是你的代码改动影响到的人，你都该加进来，PL是必须加进来的。

作为审核人

现在你是审核人员，你首先应该关注Files里涉及的所有改动文件

在这些改动的后面会有改动量：

删了多少，减了多少行都在这里可视化了

每一个文件都点进去看一看，确认没有问题（假如你的部分被影响到了，那就是有问题，其余的问题让PL去沟通）后，在这里投票（珍惜为数不多的机会）：

最终代码通过，自动merge到主干代码中。

四.常见问题

代码冲突

假如有复数名coder在对同一个模块进行开发，将同一个文件push到了gerrit上，然后竟然还都审核通过了，就会在merge的时候发生冲突。

这个叫merge conflict.

解决方法一般是：

1. 你（或者别的coder）强行push其中一个版本的文件

2. 在其他人的change页面，找到：

在Download patch里找到cherry pick，复制命令行，在本地代码库git运行

3. 你的代码里就会出现别人的代码merge之后的结果，也就是git 自动merge的结果，有点绕，我解释一下：就是说，现在你的代码是git上merge之后的代码，是报错的代码，有冲突的代码。

看到冲突才能解决冲突，之后你就可以在本地修改，删除或是合并，然后再次add、commit、push三板斧，冲突就被顺利解决了。

 详细请看：

https://wenku.csdn.net/answer/aafaa5852ab651588863e00c90736fa1

4. 之后在Gerrit界面，rebase一下

你会发现状态变为了Active：

这样就成功了。

推翻重来

1.有的时候，比如说晚上下班前，你急急忙忙在新文件里修改了几行，没来得及试就下班回家了，第二天发现无法编译，要找bug实在太麻烦，因为这是新文件里的小问题，没必要花太多时间，不如推翻重来

2.你有了新的思路，想要把之前的全部改动删除，但改动太多，删多了容易出现新bug

3.心情不好，就是想重写代码

以上等等情况，你可以使用两种方式推翻重来：

单个文件使用：

git checkout FilePath/FileName

该文件就会回溯到最新代码里的状态

全部重来：

git reset --hard HEAD

代码将回到你最后一次提交的状态