最近和同事 code review 时遇到一点问题,假如他提交了一个分支,共 10 个 commits。
我可以按照两种方式阅读代码:
把两个分支不同的文件挑出来很费时间(可能有 20 个文件)。至少 Gitlab、Tower、SourceTree 都做不到。
同一个文件频繁被修改,我压根不关心作者的心路历程,我只关心最终的代码是什么样子。
每每 review 代码,我都有这种感觉。
#2 楼 @xiaoronglv review 得不多,好像统一 review 比较好。逐个 review 有时会看到个错误,想要评论,发现下一个 commit 修复了,这就浪费时间了。
我们现在大多数是用 2 的方式来 review,结果固然重要,但心路历程有时候更能反应很多的问题和经验教训啥的,所也我们有时候也关心。但是 2 对于 Commit 的组织,大小,原子性,有可能要求更高,我们 Team 中比较注重这些,所以感觉还好。但是有的时候也用 1 的方式,但一般都是碰到比较大的变动的时候,但是其实感觉还是上边说的那些没做到位。
对于 @Rei 提到的情况我们也会碰到,不过我们都是 Team 每天找一段时间一起围着一台机器 Review,所以一般发现错误如果已经被后边修了,“当事人”就会直接解释一下,顺便还能给大家提个醒,感觉还好。
选 1 并且用 github 或者 bitbucket 来看 diff,我只看重结果,有 comments 也是针对结果而不是过程。去年写了一篇文章 http://yedingding.com/2013/08/08/dig-into-code-review-process.html