1.介绍

以前公司用gitlab做git仓库服务器，后来跳槽了后的公司用gerrit作为git仓库服务器在提交习惯上能明显感觉到差异。所以记录下，也让和我一样被弄混的人能理清思路。

2.两种分支使用方法

讲到分支合并从网上介绍的比较多的是merge，但还有另外一种方法是用rebase，我现在所在的公司就是主要用rebase。与merge不同，通过rebase整出来的主线就是干净的一条线，不会像merge那样不断有分支往主线合并。两种模式的区别可以参考以下两幅图。这两幅图引用至https://waynerv.com/posts/git-rebase-intro/
merge：

rebase：

在同样使用feature分支来开发的情况下，两种模式的区别还是很清晰的。但用rebase好像一般都不在本地多拉出条feature分支，这就导致部分步骤有些模糊了。
还是先看下merge

在我画的这图里基本可以看出核心点在节点E，无论是正常合并还是解决冲突，都会产生节点E，核心要领就是

git chekcout feature
git merge Master

有冲突解冲突，解完后add ，commit，就会生成新的节点E；没冲突也会生成节点E，后续push到服务器（gitlab）再请求合并到主线就行了。这个就不做过多的介绍。
再看rebase

由于不生成feature分支，在解决冲突是使用命令
git pull origin Master --rebase 来将远程分支同步到本地
相当于在Master主线上使用命令git rebase origin/Master
若不存在冲突，相当于直接把B，C搬到D后面
若存在冲突，这修改冲突的变化会并入B节点，相当于B要变成B‘，若冲突还独立涉及到C, C也会有相应的变化。合并完后再push流程上就没什么差异了
涉及到的命令相当于

git pull origin Master --rebase
#修改文件，拿vscode看吧，理论上有那些修改能一目了然
git add
git rebase --continue

此外，push命令在gitlab和gerrit使用上也有区别
（1）gitliab由于能自己生成分支，推哪个分支根据实际情况推，反正推上去后再将服务器上的那个特征分支合并入主线即可。
（2）gerrit好像并不强调特征分支合入主线这个点，更多的是强调将某个commit合入主线，push命令则相当于推到一个临时的主线分支上

#gitlab
git push origin feature:feature
#gerrit
git push origin HEAD:refs/for/master

2.gerrit页面介绍

push成功后就能在gerrit看到对于commit id的提交了，每个commit id对应一个页面，这也是为什么说gerrit似乎主要是看commit，而非分支合并的原因了。

以qt这个gerrit页面为例
1.里面主要是review，自检+1，一些代码流程相关的，这里不做介绍
2.一些提交代码时的要求，如果接触过些些代码上库时要自动化测试的东西，那这里就会显示出来，例如一些冒烟测试，如果自动测试没通过，那代码是上不了库的
3.log，上面有提到冒烟测试，像冒烟测试进行到哪一步了，到哪失败了，相关的log就会在这个区域显示
4.取消该次提交