各位团队的 codereview 是在提交到代码库前还是后做的呢？
如果提交前做，那么开发进度就要受 reviewer 的时间影响。
review 前做，一般都是“ hi 我提了一个 review，因为等着合并测试，麻烦快点”。但 reviewer 不一定有时间啊，或者需要大量的时间研究别人的代码，因为催，导致 review 效果下降。
如果提交后做，怎么确保 review 的意见会被整合到代码库中？
因为代码已经提交了，可能进入到下一轮测试甚至上线了，没有什么好的强制措施不让代码上线。你总不能说各个团队已经测试好了，因为你的 review 没过不让上线吧？
或者代码提交之后已经投入资源做进一步测试，这个时候依据 review 结果再修改，可能之前的测试就都白费了。
另外问下用什么工具做 review 体验比较好？我们现在用的是 gitlab，但一旦是一个大提交，页面卡得动不了。
 |
1
Tonni Dec 5, 2018  1
commit -> pull request -> code review -> merge.
> 如果提交前做，那么开发进度就要受 reviewer 的时间影响 所以要把 code review 算到开发进度估算时间里面。 > 如果提交后做，怎么确保 review 的意见会被整合到代码库中？ 线上紧急情况可以发一个 pull request 测试功能正常后直接合并，上线后再去 pull request 上面 review。先上车后补票。 |
 |
2
wdv2ly Dec 5, 2018 via Android
提交后，合并前，进行
|
 |
3
insomnia1232 Dec 5, 2018
肯定 merge 前做 merge 后做还有什么意义 提交太大就任务分的有问题 没有足够细化
|
 |
4
laike9m Dec 5, 2018 via Android
异地 review 确实会影响效率，但有时候也没办法
|
 |
5
maichael Dec 5, 2018
1. 提交后，合并前做 review。合并测试可以在合并前就做。
2. 合并后再做 review 的效果会很差。 3. 有大提交的存在说明持续集成执行的有问题的。用什么工具都好，大提交对于 reviewer 的体验都很差。 |
 |
6
coderluan Dec 5, 2018
一般分两个分支或者两个库，一个 dev，一个 release，dev 随时提交随时测试随时合并，release 只放 review 和全面测试之后的代码，最后只保留 release 部分。
|
 |
7
cjw1115 Dec 5, 2018
现在基本流程是
从 main branch 出 dev ---> dev 上写代码 ---> submit ---> code review ---> merge main to dev ---> resolve conflicts ---> merge dev to main |
 |
8
th00000 Dec 5, 2018
merge 前做
如果有人把 rm -rf / 提交进代码库了怎么办 |
 |
9
xiubin Dec 5, 2018
merge request -> review -> 提测 -> 测试通过 -> merge into master
|
 |
10
clino Dec 5, 2018
我们合入前经过 code review 改个四五次以上也有不少，一般都会改个两三次
|
Select Language