这是一个创建于 2100 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司坚持使用 Gerrit，并执行 code review，不经过 reivew 代码无法发布测试。项目 owner 没空 review 时候很耽误时间。感觉还是 Gitlab 这是 protect branch 比较合理，merge 时候 review
 |
1
ospider 2019-03-25 16:40:42 +08:00
gerrit 挺好用的呀？有啥不好的？
|
 |
2
mrgeneral 2019-03-25 16:43:36 +08:00
这个和 Gerrit 没有关系吧，就是 CR 这步在哪个阶段做的问题。
Gerrit 最可怕的是不知道哪里冲突了，死活提交不上去，只能 git stash 然后重来😂 |
 |
3
mantis 2019-03-25 16:49:38 +08:00
界面不太跟得上时代
|
 |
4
shily 2019-03-25 16:55:34 +08:00
“ owner 没空 review 时候很耽误时间”, 换成啥玩意都解决不了的问题。
@mrgeneral 看提示！看提示！！看提示！！！重要的事情说三遍。目前还没有发现啥大问题，都是可以通过提示可以解决的。但我的很多同事都直接默默的解决或直接来问我。 |
 |
5
kaneg 2019-03-25 16:57:27 +08:00
是否有空 Review 是公司流程和开发人员整体水平的问题。
Gerrit 能够做到每个人的提交不会影响到其他人，这个对一个大 team 开发是很有好处的。 至于没有 reivew 的 代码无法发布测试完全是你们的 DevOps 的水平来决定的。我们这边完全可以做到自己的代码提交到 Gerrit 之后可以 构建-> 测试->代码质量扫描（ Sonar ）-> 发布个人 build-> 安装个人实例一条龙服务。而这一切与 Code Review 都是并行的。也就是做到开发提交一行代码到 Gerrit，等待若干时间就可以在一个全新创建的个人实例上看到自己的改动是否与期望一致。而是否能够通过 Code Review 则是 Reviewer 的事。 当然 Gitlab 能否做到这一切我不清楚，毕竟没用过。但是 Gerrit 带来的好处却是实实在在的。 |
 |
6
SevenJ 2019-03-25 16:58:52 +08:00
用过，Gerrit 没毛病，还是人的问题
|
|
7
mrgeneral 2019-03-25 17:02:31 +08:00
@shily 我记得很多次提示 changeId 缺失，然后其实不是本次提交带来的，可能是 merge 了老的 commit 带来的，老的 commit 没有 changeId，所以需要回到老的 commit 去补上 changeId，又会带来新的连锁反应，so，最后还不如重新拉个分支，把自己的改动重新提上去。
PS：我们是中途接入的 Gerrit。 |
 |
8
idamien 2019-03-25 17:29:43 +08:00
再一个主要是看到底是在审查什么，如果单纯的用 gerrit 的目的是为了格式，代码规范什么的，我觉得一点也没有必要。
做代码审查的人，必须要对代码足够熟悉，否则你提交了修改，他也是看不懂深层次的东西，也是白搭。 |
Select Language