Phabricator,gerrit,gitlab code review方式对比

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

CR方式\ 对比项目	Phabricator Differential	Phabircator Audit	Gerrit	Gitlab
cr类型	Pre-commit Review	Post-commit Review	Post-commit Review	Post-commit Review
cr操作	通过命令行工具Arcanist提交diff自动生成Review Request。 一次完整的review流程如下： 1、新建分支：feature01 2、提交代码，执行命令： arc diff origin/dev 3、在打开的notepad 界面中，填写 Test Plan，Reviewers，Subscribers 4、打开命令行显示的url：http://phabricator.tools.vipshop.com/D35 页面中进行review 5、代码提交人查看review结果，修改代码后，直接提交代码到远程分支	通过将仓库托管在Phabircator中，通过Herala的方式配置规则强制Code Review	需要将仓库url改为Gerrit url。Gerrit通过hock的方式将修改同步到远程的gitlab仓库。review流程如下： 1、修改代码后，提交到Gerrit 2、在Gerrit中web页面中选择review人 3、收到review完成邮件后，提交者在Gerrit web页面中通过submit，将代码同步到gitlab仓库	完全不需要改变任何现有的开发流程和开发方式。review方式如下： 1、修改者修改完成后提交代码到远程仓库 2、线下邀请指定reviewer在gitlab的页面进行review 3、修改者通过gitlab上的comment修改代码
优点	1、通过命令行自动生成review request，reviewer收到邮件后代码review。 2、review 界面友好，可以合并多次commit进行review（因为是基于分支diff） 3、相关功能强大，比如代码管理，bug管理，任务管理，但都不是所需要的功能	和正常提交没有什么区别，用户学习成本低，不需要对现有开发习惯进行改变	不需要对当前开发方式有太多的改变。	1、开发方式方式完全不需要改变 2、不需要block住开发流程，有pre-commit的有点
缺点	1、需要另外安装和配置Arcanist工具 2、每一次提交需要创建一个分支 3、只能通过命令行提交生成review request（可以在界面生成，但是效率更低） 4、arc diff 需要在另外打开的文本编辑器中填写review信息后关闭才能回到命令行中，这个切换过程稍有不便（可以配置window 的git bash vim编辑器解决减轻这个成本）	1、对于原有的仓库需要修改remote地址 2、仓库需要托管在Phabircator中，而公司的代码仓库都是在gitlab中 3、会block住提交。在code review未完成之前不能提交到代码	1、提交有所区别，需要增加额外的步骤。不过intellij工作支持可以减轻这部分工作量 2、如果存在一个提交未review，那么后续的提交需要合并提交才能再次提交review 3、会block住开发流程，review完之后才能提交到远程仓库 4、需要改变remote url。和Phabricator类似。	1、review的方式有点类似与comment，没有很好的代码review约束性和review（比如不能指定review人，不能关联其他提交） 2、review的功能比较薄弱，仅仅是一种代码comment形式，需要很高的代码review意识以及代码模块化意识（小量模块化频繁提交，否则一次大量提交会导致review异常困难 -- 不过大批量提交的review困难问题在其他方式也存在）
备注	不是公司主流的code review工具。在使用和技术支持上帮助不够好。目前几乎没有团队在使用	1、block住流程从另外的角度上看也是优点。可以强制培养review的习惯。待review的意识加强之后，再使用其他主观review方式会更加容易推行 2、公司技术支持比较好，实践较多	从使用界面上个人感觉最为友好，也最轻量。虽然功能简单，但不失可以作为一种代码review的入门，培养代码review的习惯。 因为此方式对开发习惯和工作流程上零侵入。为了有好的review效果，对代码的组织能力要求比较高。 也正是如此，过于灵活轻量会导致主动性不高的情况下，推行效果不好

来源：oschina

链接：https://my.oschina.net/everxu/blog/3149249