拯救狗屎代码:基于 Gitlab 的代码审查,简单实用

作者:刘凯_7013
https://www.jianshu.com/p/5d764b52ea88

code review 的目的是提高代码质量,减少开发bug,俗话说,三人行必有我师,众人拾柴火焰高。

gitlab提供了code review机制,对基于gitlab的code review,直接以具体例子的形式做个实践总结。

gitlab提供了两种代码merge机制:

1)在本地将源分支(Source branch)代码合并到目标分支(Target branch),然后Push到目标分支(Target branch)

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

这两种方式仅有第2种适合code review,所以我们要做的事情是设置权限,拒绝本地merge后push到远端的操作。

在第2种方式中 发起merge request后,由有merge权限用户做code review,通过后执行merge操作。

具体操作如正文

一,分支设置

第一步,创建项目和分支。

分支结构和功能依据具体团队的规范来定,这里仅供参考。

推荐阅读:大厂 Git 提交规范是怎么做的?

关注微信公众号:Java技术栈,在后台回复:git,可以获取我整理的 N 篇最新 Git 教程,都是干货。

创建项目并创建分支如下

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第1张图片

其中 release为预发布分支,develop为测试分支,develop-1为开发分支。

release,develop,master都是固定的分支,有固定的功能。

本例中假设流程开发如下:

1. 每次需要新feature时,从master拉取开发分支,比如develop-1。

2. master有更新及时合并到develop-1,develop,以及release。

3. develop-1开发完成后合并到develop,部署测试环境。

4. develop环境测试通过后,合并develop-1代码到release环境,做预发布测试。

5. release环境测试通过后,将develop-1代码合并到master,上线。

第二步,设置分支merge权限

这一步的是实现code review的关键,也就是控制分支的merge 权限。之后只有有merge权限的责任人才能submit merge请求,没有merge权限的只能提交merge请求,等待有权限的review后submit,则合并成功

具体设置位置:

项目首页→Settings->Repository→Protected Branches

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第2张图片

将master,develop,release三个分支设置成只允许maintainers merge,不允许任何人push,也即在杜绝了上文说的从本地merge,push到远端的情况

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第3张图片

二、具体操作

这里描述从代码修改,提交,发起merge请求,到code review后merge submit的整体流程。

第一步  开发分支代码修改,提交,push到远端

feature的开发分支不做具体的保护设置,即开发人员可以修改后,add,commit,push origin,这里不做详细讲解,push之后,可以在分支页面看到相应commit日志。如下。

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第4张图片

第二步 create merge request

注意上图右上角有一个按钮,create merge request,发起merge请求后,进到页面。

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第5张图片

选择source branch 和Target branch,这里我选择的是develop-1到release(假设到了预上线阶段),点击compare branches and continue。

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第6张图片

页面中选择Assignee,指定reviewer,指定人会受到邮件。下面的approvers以及Approvals required,是批准人和最少批准个数。

填写Approvals required后,必须经过指定个数以上的人批准才能合并。

点击submit merge request。进到merge request页面。

第三步 code review

收到邮件的reviewer通过merge request 页面可以看到代码修改记录,并增加commond,其他人也可以通过commond进行讨论。

无问题可以点击merge通过或者不通过则点击右下角的close merge request。

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第7张图片

第四步 查看所有merge请求

在项目页面的merge request页面可以看到所有open状态,close状态和merged状态的merge 请求。

推荐阅读:Code Review两年实战经验分享。

三、可能遇到的问题

遇到冲突怎么办

多个分支向一个分支合并代码等流程中,往往会形成版本冲突。此时,提交merge request后的页面如下:

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第8张图片

我们发现,merge按钮置灰,同时出现了resolve conflicts以及merge locally的按钮。点击resolve conflicts。出现解决冲突的页面

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第9张图片

页面可以通过use ours指定使用当前分支(发起merge request的源分支)代码或者use theirs来指定使用目标分支代码。或者点击 edit inline直接通过编辑页面编辑(更通用)。

拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第10张图片拯救狗屎代码:基于 Gitlab 的代码审查,简单实用_第11张图片

ok,我们已经处理完冲突,点击下方submit按钮。
返回merge request页面,等待远端冲突解决完成后,merge按钮正常。

四、总结。

1. 关于分支设置

以上仅是一个分支设置的示例,我们可以根据团队风格,和具体问题具体分析。

比如多人同时开发一个需求,可能需要拉取一个feature分支后再根据该feature分支拉取个人开发分支,开发完成后和并feature再合并develop,release,master等

2. code review 流程

总结下code review流程

1)创建好 测试分支,release分支,并配置测试分支,release分支,master分支的merge权限

2)开发分支开发完成后push到远端,通过页面提交merge request,指定reviewer和审批人,一般指定reviewer即可。

3)reviewer 通过代码review,没有问题,可以点击merge,完成合并操作。如果有问题,可以发起讨论,或者直接关闭merge请求。

code review 流程完成。

关注公众号Java技术栈回复"面试"获取我整理的2020最全面试题及答案。

推荐去我的博客阅读更多:

1.Java JVM、集合、多线程、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、后端、架构、阿里巴巴等大厂最新面试题

觉得不错,别忘了点赞+转发哦!

你可能感兴趣的:(拯救狗屎代码:基于 Gitlab 的代码审查,简单实用)