基于gitlab的code review

[willson-wang]

为什么要做code review

好处

1. 提升代码质量
2. 方便组内同事交流
3. 提高自己的编码水平

坏处

1. 流程相对变复杂了一点
2. code review需要消耗的一定时间，但是我们一般都是基于业务编程，时间上可能来不及
3. 流于形式

任何事情都是利弊共存的，还是需要结合当前团队的人员组件来决定是否需要进行code review

code review 工具

现在有比较受好评code review工具有Facebook的Phabricator，Google的Gerrit，他们都是开源的.另外微软也有他的code review工具TFS(Team Foundation Server),据说也挺好用，不过是收费的。不过现在大家用得最多的code review方式是基于Pull Request工作流方法，结合gitlab或者github来使用。

code review 流程

首先我们代码仓库是有对应的分支模型的，如常见的flow模型；其次我们需要在gitlab做好权限管理。每个成员在项目里都有对应的角色，例如owner，master，developer等。然后项目代码里设置受保护分支，master一定是受保护的分支，还可以根据需要设置其他分支为受保护分支。developer权限的成员是不能向master或者其他受保护分支push代码的。

所以有了前面的前置条件之后，我们code review之后的，一个开发流程如下所示

本地建立一个开发分支feature->本地编写代码->push分支代码->gitlab上发起一个合并请求(merge request)->审核人员审核代码，如有需要，提出修改意见->开发人员修改代码-->审核人员审核通过，合并代码，删除分支

详细的操作如下所示

1. 根据当前需求创建一个本地分支，如需求是更换首页列表文案

git checkout -b f-20200930-change-home-list-txt-xxx

2. 在当前分支进行开发，开发完成并本地自测之后，将代码push到远程

git add .
git commit -m 'feat:更换首页列表文案'
git push origin f-20200930-change-home-list-txt-xxx

3. 进入gitlab创建一个合并请求，如下所示，具有gitlab高低版本稍微有点不一样

低版本，以GitLab 7.2.1为例

高版本，以GitLab 12.6.2为例

4. 创建合并请求之后，需要进行code review的同时可以进行review 代码，注意这里可以选择不同的方式通知需要code review的同事

5. 同事审核代码，如有需要，提出修改意见

6. 继续本地修改代码，然后push代码

7. 继续创建重复步骤3

8. 直到审核通过，代码合并到目标分支，然后将远程源分支删除

总结

code review只是一种督促我们的手段，要写出好代码，还是需要靠自己