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 教程，都是干货。
创建项目并创建分支如下
其中 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
将master，develop，release三个分支设置成只允许maintainers merge，不允许任何人push，也即在杜绝了上文说的从本地merge，push到远端的情况
二、具体操作
这里描述从代码修改，提交，发起merge请求，到code review后merge submit的整体流程。
第一步 开发分支代码修改，提交，push到远端
feature的开发分支不做具体的保护设置，即开发人员可以修改后，add，commit，push origin，这里不做详细讲解，push之后，可以在分支页面看到相应commit日志。如下。
第二步 create merge request
注意上图右上角有一个按钮，create merge request，发起merge请求后，进到页面。
选择source branch 和Target branch，这里我选择的是develop-1到release（假设到了预上线阶段），点击compare branches and continue。
页面中选择Assignee，指定reviewer，指定人会受到邮件。下面的approvers以及Approvals required，是批准人和最少批准个数。
填写Approvals required后，必须经过指定个数以上的人批准才能合并。
点击submit merge request。进到merge request页面。
第三步 code review
收到邮件的reviewer通过merge request 页面可以看到代码修改记录，并增加commond，其他人也可以通过commond进行讨论。
无问题可以点击merge通过或者不通过则点击右下角的close merge request。
第四步 查看所有merge请求
在项目页面的merge request页面可以看到所有open状态，close状态和merged状态的merge 请求。
推荐阅读：Code Review两年实战经验分享。
三、可能遇到的问题
遇到冲突怎么办
多个分支向一个分支合并代码等流程中，往往会形成版本冲突。此时，提交merge request后的页面如下：
我们发现，merge按钮置灰，同时出现了resolve conflicts以及merge locally的按钮。点击resolve conflicts。出现解决冲突的页面
页面可以通过use ours指定使用当前分支（发起merge request的源分支）代码或者use theirs来指定使用目标分支代码。或者点击 edit inline直接通过编辑页面编辑（更通用）。
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 流程完成。
