基于Gitlab的Code Review最佳实践
环境说明
- 本文提到的社区版本和企业版本信息如下:
1 | 社区版本:GitLab Community Edition 11.11.4 |
Git Flow简介
- 经典的
git flow
图中,有Master、Hotfix、Release、Develop、Feature
等分支。每个分支的作用各不相同。各个分支的主要功能如下:
分支名 | 功能 |
---|---|
Master | master分支存储了正式发布的历史版本,是一个功能完整且随时可以发布到线上进行部署到可用分支。基于tag进行标记,方便快速回退。 |
Hotfix | Hotfix分支是用来修复线上bug,快速打补丁用的。该分支是基于线上master分支的tag fork而来,bug修复完成后,该分支需合并到master分支和develop分支。 |
Release | Release是一个发布分支。从这个时间点开始,develop分支继续合并新功能,但新功能不再合并到该分支。在该分支上可以有一些bugfix,当然bugfix也要同步合并到develop分支中。一旦所有工作都准备好,release分支合并到master上,并在master上打一个tag,标记为版本号。 使用专门的发布分支,可以使团队成员在完善当前发布版本的同时也能基于develop分支继续开发新功能。在实际开发过程中,我们将Release分支和Master分支合并成了一个Master分支,每周的版本发布是基于Master发布的。 |
Develop | Develop分支作为功能的集成分支。后续的版本发布,feature新功能开发都是基于这个分支fork进行。 |
Feature | Feature分支则是功能分支,使用develop分支作为父分支。当新功能开发完成后合并到develop分支。Feature分支不应该直接合并到master分支上。 |
Gitlab Code Review方式
- 一共有2种常见的方式来进行
gitlab
的code review
,本文主要介绍 远程方式的使用。-
**本地方式:**在本地将源分支
(Source branch)
代码合并到目标分支(Target branch)
,然后Push到远程的目标分支(Target branch)
。 -
远程方式: 将源分支
(Source branch) Push
到远端,然后在GitLab
前端指定目标分支(Target branch)
发起Merge Request
,对目标分支(Target branch)
拥有Push
权限的用户执行Merge
操作,完成合并。
-
Gitlab Code Review配置
- 在
Code Review
执行之前,进行一些合理的配置会有事半功倍的效果,下面我们来谈谈有助于Code Review
常见功能。
Approvals与Merge Request定制功能
- 可对
Merge Request
进行定制,如下图,要求MR
可点击合并的条件是:pipeline
必须返回成功,同时所有discussions
已被标记为resolved
。其中默认删除源分支的功能只有企业版(Starter)才支持。
- 关于审核员规则(该功能只有企业版才支持),这里推荐按照团队的情况进行定制:一种是核心成员,经验丰富,对成员代码把关;另一种是,新人团队,随机抽取,互相监督,互相学习。
Issue与Merge Request的模版功能
- 在开发流程比较固定的情况下,我们可以对
issue
和Merge Request
的内容格式进行模版化,如下图,我们以code_review/project1
这个repo
为例,在仓库根目录下新增了.gitlab/issue_templates/Issue.md
和.gitlab/merge_request_templates/Merge_Request.md
两个文件,分别代表设置issue
和Merge Request
的模版内容。详细说明可参考官方说明。
issue
的模版效果如下图所示:
Merge Request
的模版效果如下图所示:
Issue与Merge Request的联动功能
- 当提交到master默认分支时,
gitlab
支持提交信息带上:关键词 + issue编号来联动issue
(注意关键字后面必须跟上一个空格)。常见的关键字有:fix/fixes/fixed、close/closes/closed、resolve/resolves/resolved,issue
编号可以参考下图:
案例参考
- 下图为实际的操作案例
Merge Request
联动issue
的界面。
issue
里面联动Merge Request
的界面。
Gitlab的Code Quality功能
- 我们可以利用开源的
Code Climate Engines
工具,对仓库代码进行质量检查。Code Climate Engines
可以免费使用,但是report
在mr
界面的report
展示需要企业版(Starter)才支持。具体说明可参考官方文档,要使用该功能,需要配置好gitlab-runner
的Docker-in-Docker
模式,其中gitlab-runner
的config.toml
配置可参考如下:
1 | [[runners]] |
- 对应的
.gitlab-ci.yml
配置可参考如下:
1 | code_quality: |
-
这里需要注意的是,当检查的代码文件数较多时,需要根据情况适当提高
ENGINE_MEMORY_LIMIT_BYTES
的值,否则会因为内存不足检查失败。同时gl-code-quality-report
依赖上次master分支是否有diff
而进行展示,故首次使用时,需触发下面的empty-report
这个stage
,上传一个空的gl-code-quality-report.json
文件。 -
上传以后,在
MR
的界面,可以看到类似如下的界面,代表Code Quality
功能启用成功。
Gitlab Code Review实践
- 我们以一个测试项目为例进行简单的
Code Review
说明。
第一步:选择源目标分支
- 如下图,选择源分支和目标分支,新建MR:
第二步:设置MR相关参数
- 注意下面的
Merge request dependencies
和Approval rules
只有企业版(Starter)才支持。
第三步:开始review
- 开始
code review
,多人进行discuss
和comment
,其中多人Finish review
的功能只有企业版(Starter)才支持。如下图:
第四步:审批解决discuss
discussions
未解决时,无法点击Merge
按钮。当所有discussions
已经解决,并且pipeline
执行成功,approve
批准以后,才可点击执行。下图为了演示方便,我取消了本次的approve
。
第五步:解决合并冲突
- 如果合并过程产生了冲突,如下图所示,提示你有2种方式来处理。一种是直接在web前端界面进行修改。另外一种是在本地进行修改。解决冲突时需要拉上团队里的其他成员一起讨论,留下最终需要的内容进行提交即可。
- 这里我为了演示方便,我选择在前端上直接修改冲突,点击
Resolve conflicts
,出现如下界面,按照图中三个步骤操作即可。
第六步:融入目标分支
- 当
discuss
已经解决、pipeline
执行成功、Approval
审批完成、Conflicts
已经解决的时候,可以看到Merge
按钮为绿色,最终点击MR融入目标分支。
建议与总结
- 选择社区版本(CE)还是企业版(Starter),取决于业务的需求。如果业务的
Code Review
过程强烈需要多人审批(approval)、多人Finish review
、Code Quality
的report在MR展示等功能,则优先考虑企业版,否则社区版本做也是一个不错的选择。
赞赏一下