【围观】麒麟芯片遭打压成绝版，华为亿元投入又砸向了哪里？>>>
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效果，对代码的组织能力要求比较高。
也正是如此，过于灵活轻量会导致主动性不高的情况下，推行效果不好