The purpose of code review is to improve code quality and reduce development bug, the saying goes, three lines must be my teacher, Many hands make light.
gitlab provides a code review mechanism, based gitlab of code review, summarized in the form of direct practice to be a concrete example.
gitlab merge the code provides two mechanisms:
- The local branch source (Source branch) code into target branch (Target branch), then the branch target to Push (Target branch)
- The source branch (Source branch) Push to the remote, and then specify the target branch in GitLab (Target branch) launched Merge Request, the user has permission to merge the branch target (Target branch) Merge to perform the operation, the completion of the merger.
Both methods suitable for only the first two kinds of code review, so we need to do is to set permissions, refused after local merge push to operate the remote. After initiating merge request In the second mode, the user has permission to merge do code review, perform merge operations after the adoption.
The specific operation body
A branch set
First, create projects and branches.
Branch structure and function in accordance with norms specific to a given team, here for reference purposes only.
Create a project and create the following branches
Creating a branch
Which is a pre-release distribution branch, develop test branch, develop-1 is a development branch.
release, develop, master branches are fixed, there is a fixed function.
This example assumes that the process developed is as follows:
1. Each time a new required feature, a branch developed from pull master, such as the develop-1.
2. master merge updates in a timely manner to develop-1, develop, and release.
3. develop-1 developed after the completion of the merger to develop, deploy test environments.
4. develop after testing environment, develop-1 combined codes to release the environment, do pre-release testing.
5. release the testing environment, the develop-1 code into the master, on the line.
The second step, set up a branch merge permissions
This step is key to code review, which is the authority to control merge branches. Only after the merge authority responsible to submit merge requests, no rights can only be submitted merge merge request, waiting for permission to have the review after submit, the successful merger
The setting here:
Project Home → Settings-> Repository → Protected Branches
Permission settings page
The master, develop, release three branches arranged to only allow maintainers merge, allow anyone to push, i.e. in the case to eliminate the above said locally merge, push the distal end
Permissions results
Second, specific operation
Code changes from the description herein, submit, initiate a merge request, the code review merge to submit the overall process.
The first step in the development branch code modifications, submit, push to the remote
After the feature development branch is not specifically protected settings that developers can modify, add, commit, push origin, not to explain in detail here, after the push, you can see the corresponding commit log branch page. as follows.
commit log
The second step create merge request
Note that a button on the upper right corner of FIG, create merge request, the request is initiated merge, page into
Select the source and target branch branch
Select the source branch and Target branch, where I chose the develop-1 to the release (assuming that the pre-stage to the line), click on the compare branches and continue.
Published merge request
Page, select the Assignee, specify the reviewer, the nominee will receive the message. The following approvers and Approvals required, is approved and the approval of a minimum number.
After filling Approvals required, must be more than a specified number of people in order to approve the merger.
点击submit merge request。进到merge request页面。
第三步 code review
收到邮件的reviewer通过merge request 页面可以看到代码修改记录，并增加commond，其他人也可以通过commond进行讨论，
无问题可以点击merge通过或者不通过则点击右下角的close merge request。
review
第四步 查看所有merge请求
在项目页面的merge request页面可以看到所有open状态，close状态和merged状态的merge 请求
三、可能遇到的问题
遇到冲突怎么办
多个分支向一个分支合并代码等流程中，往往会形成版本冲突。此时，提交merge request后的页面如下：
冲突页面.png
我们发现，merge按钮置灰，同时出现了resolve conflicts以及merge locally的按钮。点击resolve conflicts。出现解决冲突的页面
解决冲突.png
页面可以通过use ours指定使用当前分支（发起merge request的源分支）代码或者use theirs来指定使用目标分支代码。或者点击 edit inline直接通过编辑页面编辑（更通用）。
edit inline.png
ok，我们已经处理完冲突，点击下方submit按钮。 返回merge request页面，等待远端冲突解决完成后，merge按钮正常。
冲突解决完成.png
四 总结。
1. 关于分支设置
以上仅是一个分支设置的示例，我们可以根据团队风格，和具体问题具体分析。
比如多人同时开发一个需求，可能需要拉取一个feature分支后再根据该feature分支拉取个人开发分支，开发完成后和并feature再合并develop，release，master等
2. code review 流程
总结下code review流程
（1）创建好 测试分支，release分支，并配置测试分支，release分支，master分支的merge权限
(2) development after development is completed push to the remote branch, merge request filed by page, specify the reviewer and approver, generally designated reviewer can.
(3) reviewer through code review, no problem, you can click on the merge, to complete the merge operation. If you have questions, you can start a discussion, or simply close the merge request.
code review process is complete.
