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