Phabricator,gerrit,gitlab code review方式对比
< 返回列表时间: 2019-12-29来源:OSCHINA
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里?>>>
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效果,对代码的组织能力要求比较高。
也正是如此,过于灵活轻量会导致主动性不高的情况下,推行效果不好
热门排行