1. 首页
  2. 科技部落

基于GitLab的Code Review指南

一、前言

1、本文主要内容

  • GitLab Code Review机制说明
  • Git Workflow 与 Git Code Review Workflow
  • GitLab Code Review 配置说明
  • GitLab Code Review 流程演示
  • GitLab For IDE 插件介绍(JetBrains等等)
  • 如何提高Code Review的效率与质量

2、GitLab Code Review机制

GitLab可以在分支合并的时候支持两种方式:

  1. 在本地将源分支(Source branch)代码合并到目标分支(Target branch)然后Push到目标分支(Target branch)
  2. 将源分支(Source branch)Push到远端,然后在GitLab指定目标分支(Target branch)发起Merge Request,对目标分支(Target branch)拥有Push权限的用户执行Merge操作,完成合并。

    也就是说,使用GitLab进行Code Review就是在分支合并环节发起Merge Request,然后Code Review完成后将代码合并到目标分支。

3、本文适用的环境说明

工具/环境版本
GitLabGitLab.com、GitLab 社区版皆可
IDEJetBrains(IntelliJ IDEA、PyCharm、PhpStorm、WebStorm、RubyMide、AppCode、CLion、GoLand、DataGrip、Rider、Android Studio等等)

    虽然Code Review不一定非要结合IDE来做,但是也不得不感谢JetBrains开发了几乎覆盖所有主流编程语言的IDE。

JetBrains Tools目前覆盖的主流语言有:C/C++、C#、DSL、F#、Go、Groovy、Java、JavaScript、TypeScript、Kotlin、Objective-C、PHP、Python、Ruby、Scala、SQL、Swift、VB.NET(排名不分先后)

二、GitLab Code Review 配置

1、Code Review 工作流

  • 通用Git工作流说明
基于GitLab的Code Review指南
  1. 需求确认后,从master创建develop分支
  2. 开发人员从develop分支创建自己的feature分支进行开发
  3. master分支发生变更,需要从master分支合并到develop分支、可以考虑定期合并一次
  4. feature分支合并到对应的develop分支之前,需要从develop分支合并到feature分支
  5. feature分支合并到对应的develop分支之后,发布到测试环境进行测试
  6. develop分支在测试环境测试通过之后,合并到release分支并发布到预发布环境进行测试
  7. release分支在预发布环境验证通过后,合并到master分支并发布到生产环境进行验证

分支名称约定:

分支类型名称格式说明
Mastermaster有且只有一个
Releaserelease-**可以是班车发布日期也可以是需求名称缩写,也可以根据需要只用一个release分支
Developdevelop-**通常是班车发布日期或者需求名称缩写,也可以根据需要只用一个develop分支
Featurefeature-{username}-*开个人员个人分支,*通常是班车发布日期或者需求名称缩写
  • Code Review 环节选定

    以上述Git工作流为例,开发人员在Feature分支进行开发,开发完成后Merge到Develop分支进行测试。

    那么最适合做Code Review就是Feature分支合并到Develop分的环节。

基于GitLab的Code Review指南

2、GitLab Repository 配置

    GitLab仓库相关配置以gitlab.com为例,本篇内容如果没有特别注明,也同样适用于私有化部署的GitLab CE版本

  • GitLab新建仓库&创建分支
基于GitLab的Code Review指南

仓库地址:https://gitlab.com/ken-io/test

基于GitLab的Code Review指南

新建分支:
release(from master)
develop-test(from master)、
feature-ken-test(from develop-test)

  • Protected Branches 配置

    为了保证必须以Merge的方式变更develop分支、release分支、以及master分支,我们需要对Push以及Merge权限进行限制 。

菜单:Settings->Repository Settings然后展开Protected Branches选项https://gitlab.com/ken-io/test/settings/repository

基于GitLab的Code Review指南

    这里,我们限制分支,所有的开发人员对develop分支、release分支、以及master分支均无Push权限,只能以Merge方式合并到对应分支,而且只有Maintainers(Masters)组的用户有Merge权限。

    对于通配符的分支保护,我们需要给Maintainers(Masters)组的用户Push权限,不然无法新建对应格式的分支。对于固定名称的分支:master、release等,可以限制所有角色都没有Push权限。

三、GitLab Code Review 示例

  • 变更Feature分支

    在线修改feature-ken-test分支README.md文件,为Merge Request提供基础。

基于GitLab的Code Review指南

这里随意更新一行内容,然后Commit changes即可。

  • 创建Merge Request

菜单:Merge Requests,然后点击:New Merge Request

基于GitLab的Code Review指南

Source branch选择:feature-ken-test
Target branch选择:develop-test
然后:Compare branches and continue

基于GitLab的Code Review指南

操作项/填写项说明:

操作项/填写项ken.io 的说明
Title标题,没有特殊要求保持默认即可
Description描述,需要将变更的需求描述清楚,最好附上Code Review要点
Assignee分配到的人,被分配到的人将会收到邮件通知,跟Merge权限没有必然关系,仍然是项目的Maintainers(Masters)角色拥有Merge权限
Milestone里程碑,如果没有可不选
Label标签,如果没有可不选
Approvers user批准人/审批人,必须为项目所在组成员,如果选择了批准人,那此次合并必须经由批准人批准
Approvers group批准人组,方便同时选择多个批准人
Approvals required最少批准个数,如果选了个3个批准人,Approvals required设置为1,那么只需要1个批准人批准即可
Source branch源分支,跟上一步骤选择一致,这里主要用于确认
Target branch目标分支,跟上一步骤选择一致,这里主要用于确认

    Approvers选项暂不适用于Gitlab-CE(社区版 version<=11.1.4),期望后续可以支持。
这里填写好Description,选择Assignee,然后Submit merge request即可。

  • Merge Request 操作
基于GitLab的Code Review指南

    Merge Request 创建之后就会转到该页面,被分配到的人(Assignee)会收到邮件提醒,如果需要多个人进行 Code Review,只要将该页面的链接发给其他项目成员即可。项目成员可以查看变更并评论,只不过按照之前的配置,只有Maintainers(Masters)角色的成员才有Merge的权限。

基于GitLab的Code Review指南

    在Changes选项卡中,我们可以看到所有的变更。将光标移动到行号处会出现评论按钮,我们可以点击评论按钮发起评论,这个评论是对项目成员可见的,大家可在讨论区进行讨论。最终讨论发起者有权将讨论标记为已解决resolved。

基于GitLab的Code Review指南

    当所有的问题已解决之后(如果选择了审批人也需要审批通过),Maintainers(Masters)成员点击Merge完成合并即可。

基于GitLab的Code Review指南

Merge完成之后,可以选择Remove Source Branch等操作。

develop分支合并到release分支,以及elease分支合并到master是不需要经过Code Review的,直接Merge即可。这里就省略了。

四、IDE Merge Request 插件使用介绍

    前面介绍了通过GitLab网页创建Merge Request并发起Code Review,但作为开发人员,还是结合IDE来使用会更顺手,GitLab提供了相关的api,只要我们创建相应的token,就可以供IDE插件来访问GitLab,以便使用IDE代替在网页上操作。

1、GitLab Access Token

菜单:User Settings-> Access Tokens 进入Access Token添加页面

基于GitLab的Code Review指南
说明
Name名称,根据自己喜好来即可
Expires at过期时间,最远可以选择到10年后,根据自己需要填写即可
Scopes范围,这里选择api就够用了

创建完成后,麻烦暂时保存token。因为一旦刷新或者重开页面,token就不可见了。

2、JetBrains IDE GitLab插件使用

    JetBrains提供了诸多IDE:IntelliJ IDEA、PyCharm、PhpStorm、WebStorm、RubyMide、AppCode、CLion、GoLand、DataGrip、Rider、Android Studio等等,如无意外,都适用于GitLab插件。

安装以下两个插件即可:
Gitlab Projects:https://plugins.jetbrains.com/plugin/7975-gitlab-projects
Gitlab Integration:https://plugins.jetbrains.com/plugin/7319-gitlab-integration

  • 安装GitLab插件

Settings->Plugins 进入Plugins管理页

基于GitLab的Code Review指南

点击Browse repositories并搜索gitlab

基于GitLab的Code Review指南

安装Gitlab Projects以及Gitlab Integration,然后重启IDE生效

  • 配置GitLab

在Settings界面搜索GitLab Settings

基于GitLab的Code Review指南

填写GitLab Server Url、Access Token,然后点击Add New One完成添加 如果是私有化部署的GitLab,换成对面的域名或者IP+Port即可。

  • Create Merge Request

Clone项目feature-ken-test分支到本地,变更后push到origin。
然后在菜单中选择:VCS->Git->Git Lab-> Create Merge Request

基于GitLab的Code Review指南

    这里相当于我们在GitLab网页上进行创建操作,只不过少了一些选项,也暂不支持Approvers相关选项。
    选择目标分支,被分配的人,填写好Title、Description然后点击OK即可。Merge Request创建完成后,插件会在右下角提示,点击链接即可跳转到Merge Request页面。

如果提示冲突,请先将目标分支代码合并到当前分支

  • Merge Request Manage

项目成员在菜单中选择:VCS->Git->Git Lab-> List Merge Request

基于GitLab的Code Review指南

在这里可以看到待处理的Merge Request,选中后点击Code Review就可以呼出Merge Request操作面板

基于GitLab的Code Review指南
按钮说明
Diff查看所有变更文件及差异
Comments查看、添加评论
Assign to me将跟进人指给自己
Merge执行Merge
  • Merge Request Diff

Diff界面说明:

基于GitLab的Code Review指南

    左侧是本次合并的commit记录,右侧是本次合并的文件。双击对应文件即可查看差异明细。

基于GitLab的Code Review指南
  • Merge Request Comments
基于GitLab的Code Review指南

    Comments界面可以查看指定Merge Reuqest评论信息,也可以添加评论,双击可以查看完整评论内容。但是不支持针对代码行发起讨论、对讨论标记为已解决等。


    GitLab插件还是更适用于Create Merge Request、或者对于较为简单的提交进行Code Review。如果需要讨论等功能,还是建议在GitLab页面上进行操作

3、其他IDE GitLab插件使用

  • Visual Studio

Visual Studio GitLab插件:https://marketplace.visualstudio.com/items?itemName=MysticBoy.GitLabExtensionforVisualStudio

  • Visual Studio Code

Visual Studio Code GitLab插件:https://marketplace.visualstudio.com/items?itemName=jasonn-porch.gitlab-mr

  • Atom

Atom GitLab 插件:https://atom.io/packages/gitlab

五、Code Review常见问题

1、如何提高Code Review效率?

  • 控制Merge Request代码量与频率

    有些团队会选择在项目排期时,在最后留一个Code Review时间,通常研发在自测通过后,提交给测试之前,相关开发人员在一个会议室中,集中Review代码。这可能会出现两种情况:

  • 大家各抒己见,预计1个小时的Review,1.5小时才结束
  • 发现有性能隐患,剩余的时间可能不满足代码优化了

    所以,我更建议:单个项目分多次提交Merge Request,每个Merge Request都是单个可被执行单元测试的逻辑单元。如项目中的工具类,就可以实现一个提交一个。项目中的业务功能,就可以实现一个提交一个。

  • 做好Merge Request说明

    Merge Request的标题与描述一定要准确描述提交的代码所要实现的功能以及解决问题,减少沟通成本。

反面示例:

    标题:批量创建订单功能优化 

    内容:优化批量创建订单性能

建议描述:

    标题:优化批量创建订单性能 

    内容:

  1. 合并订单中相同信息(收货地址等),减少网络传输消耗
  2. 订单创建后的通知触达由同步改为异步

2、如何提高Code Review质量

  • 要有指导性的规则

如果评判代码的好坏,不能单纯以Reviewer的经验来,必须要有团队共同认同的《代码规范》,这样参与Code Review的工程师不论是编码时还是Review代码时都有准则

对于Java工程师来说可以借鉴阿里巴巴发布的《Java开发手册》

  • 团队资深工程师的认真对待

    Code Review除了提升代码本身的质量来说,还要让参与的工程师有收获。无论规则怎么制定,终究还是需要参与的工程师来执行,如果大家互相睁一只眼闭一只眼,那么规则就会变成空的。

    经验尚浅的工程师,可以通过Code Review来学习更好的代码,而资深的工程师正是要通过Code Review这个环节帮助经验尚浅的工程师提升编码质量。所以资深工程师一定要严格要求,不能放水。不然,如果烂代码越积越多,还是得这些资深工程师来解决这个问题。

  • 团队负责人的抽查

    团队的负责人,还是要抽查Merge Request的记录,来发现大家执行过程中需要优化的事项, 不断帮助大家完善规则,做好执行。

本文来自拍码场,经授权后发布,本文观点不代表信也智慧金融研究院立场,转载请联系原作者。