基于 gitlab 的 code review
code review 的目的是提高代码质量，减少开发 bug，俗话说，三人行必有我师，众人拾柴火焰高。
gitlab 提供了 code review 机制，对基于 gitlab 的 code review，直接以具体例子的形式做个实践总结。
gitlab 提供了两种代码 merge 机制：
- 在本地将源分支 (Source branch) 代码合并到目标分支（Target branch），然后 Push 到目标分支（Target branch）
- 将源分支 (Source branch) Push 到远端，然后在 GitLab 指定目标分支（Target branch）发起 Merge Request，对目标分支（Target branch）拥有 merge 权限的用户执行 Merge 操作，完成合并。
这两种方式仅有第 2 种适合 code review，所以我们要做的事情是设置权限，拒绝本地 merge 后 push 到远端的操作。在第 2 种方式中 发起 merge request 后，由有 merge 权限用户做 code review，通过后执行 merge 操作。
具体操作如正文
一，分支设置
第一步，创建项目和分支。
分支结构和功能依据具体团队的规范来定，这里仅供参考。
创建项目并创建分支如下
其中 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 请求
三、可能遇到的问题
遇到冲突怎么办
多个分支向一个分支合并代码等流程中，往往会形成版本冲突。此时，提交 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 流程完成。
