各位有做 codereview 的团队，是提交前还是提交后来 review？

[huadi]

各位团队的 codereview 是在提交到代码库前还是后做的呢？

如果提交前做，那么开发进度就要受 reviewer 的时间影响。
review 前做，一般都是“ hi 我提了一个 review，因为等着合并测试，麻烦快点”。但 reviewer 不一定有时间啊，或者需要大量的时间研究别人的代码，因为催，导致 review 效果下降。

如果提交后做，怎么确保 review 的意见会被整合到代码库中？
因为代码已经提交了，可能进入到下一轮测试甚至上线了，没有什么好的强制措施不让代码上线。你总不能说各个团队已经测试好了，因为你的 review 没过不让上线吧？ 或者代码提交之后已经投入资源做进一步测试，这个时候依据 review 结果再修改，可能之前的测试就都白费了。

另外问下用什么工具做 review 体验比较好？我们现在用的是 gitlab，但一旦是一个大提交，页面卡得动不了。

[Tonni]

commit -> pull request -> code review -> merge.

> 如果提交前做，那么开发进度就要受 reviewer 的时间影响

所以要把 code review 算到开发进度估算时间里面。

> 如果提交后做，怎么确保 review 的意见会被整合到代码库中？

线上紧急情况可以发一个 pull request 测试功能正常后直接合并，上线后再去 pull request 上面 review。先上车后补票。

[wdv2ly]

提交后，合并前，进行

[insomnia1232]

肯定 merge 前做 merge 后做还有什么意义 提交太大就任务分的有问题 没有足够细化

[laike9m]

异地 review 确实会影响效率，但有时候也没办法

[maichael]

1. 提交后，合并前做 review。合并测试可以在合并前就做。
2. 合并后再做 review 的效果会很差。
3. 有大提交的存在说明持续集成执行的有问题的。用什么工具都好，大提交对于 reviewer 的体验都很差。

[coderluan]

一般分两个分支或者两个库，一个 dev，一个 release，dev 随时提交随时测试随时合并，release 只放 review 和全面测试之后的代码，最后只保留 release 部分。

[cjw1115]

现在基本流程是
从 main branch 出 dev ---> dev 上写代码 ---> submit ---> code review ---> merge main to dev ---> resolve conflicts ---> merge dev to main

[th00000]

merge 前做
如果有人把 rm -rf / 提交进代码库了怎么办

[xiubin]

merge request -> review -> 提测 -> 测试通过 -> merge into master

[clino]

我们合入前经过 code review 改个四五次以上也有不少，一般都会改个两三次