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

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操作。
    具体操作如正文

一,分支设置

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

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

创建项目并创建分支如下

拯救狗屎代码:基于 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张图片

commit日志


第二步 create merge request

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

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

选择源分支和目标分支

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

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

发布merge request

页面中选择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张图片

review

第四步 查看所有merge请求

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

三、可能遇到的问题

遇到冲突怎么办

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

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

冲突页面.png

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

 

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

解决冲突.png

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

 

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

edit inline.png

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

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

冲突解决完成.png

四 总结。

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 流程完成。

你可能感兴趣的:(程序员)