1，背景
首先我想先来讲讲什么是分支合并请求Merge Request(也可叫Pull Request，下文中全用Merge Request或其缩写MR指代)，以及它有什么作用（如果你对此概念有所了解，你完全可以跳过What is it）。
MR(或者PR)就是指将你开发的代码的内容以一种请求合并的方式来合并到它想去的分支上，这个请求的接收人(Reviewer)一般是项目、团队的负责人或者其他成员。
一般来讲，开发团队都对Code Review（代码复审/审查/检视）的重视程度比较高。因为Code Review的确实能够提升代码的质量以及减少BUG的产生率。
Merge Request在Code review中就是重要的一环。如果使用MR来发起合并请求，那么在代码审查时就完全可以以你本次请求的合并内容为单元进行代码审查，如果审查通过那么就成功合并。审查交由Reviewer进行，他可以是请求的接收人。如果团队多个成员坐在一起来看你的本次合并内容，那么自然Reviewer就是这些人了。一份代码经过多人的审查，代码问题发生率自然会降低，开发者在开发时也会保持良好的编码习惯，毕竟没人想被别人指点自己的代码。
不过有些团队可能并不重视Merge Request，最多也就是在dev分支（大家共用的开发分支）上检出一个新分支，然后在新分支上进行开发，然后commit -> push最后merge到 dev分支上就完事了。
下面我们将以Merge Request为目标，从建立仓库开始讲述一个完整的git工作流以及其中的git操作。
2，使用说明
可通过追踪issues创建branch，也可直接clone master之后git branch。
[lingkai.meng@etxnode01 menglingkai_test]$ git
b ca ci co cp dt l pl ps st
[lingkai.meng@etxnode01 menglingkai_test]$ git b test_0331
[lingkai.meng@etxnode01 menglingkai_test]$ git add .
[lingkai.meng@etxnode01 menglingkai_test]$ git co -m "test_0331"
D a
A adduser_sh/abc.csv
A adduser_sh/projects_add.py
D adgdg
A playbook/playbook_chrony.ymal
A playbook/playbook_zabbix.ymal
Switched to branch 'test_0331'
[lingkai.meng@etxnode01 menglingkai_test]$ git ps origin test_0331
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for test_0331, visit:
remote: http://***/lingkai.meng/menglingkai_test/-/merge_requests/new?merge_request%5Bsource_branch%5D=test_0331
remote:
To http://***/lingkai.meng/menglingkai_test.git
* [new branch] test_0331 -> test_0331
[lingkai.meng@etxnode01 menglingkai_test]$ 
确认branch代码准确无误之后，可提交代码到master，然后指定某个人进行评审。
heck out, review, and merge locally
Step 1. Fetch and check out the branch for this merge request
git fetch origin
git checkout -b "test_0331" "origin/test_0331"
Step 2. Review the changes locally
Step 3. Merge the branch and fix any conflicts that come up
git fetch origin
git checkout "master"
git merge --no-ff "test_0331"
Step 4. Push the result of the merge to GitLab
git push origin "master"