简写说明
- MR = Merge Request
- 主仓 = 组织创建的仓库（下文中是
awesome-php组织创建的awesome-one仓库）
什么是Merge Request
相信很多人都不太懂这个
MR到底是什么，通俗地说，MR就是一个merge请求。创建一个MR当然就可以理解为创建一个合并请求。MR的存在主要是为了权限控制。
Forking Workflow
用
Git的同学最开始接触的想必是Git Workflow吧。什么是Git Workflow？其实就是多人在同一个仓库上进行代码托管，然后仓库存在多个分支，一般来说每个新功能会创建一个分支，然后根据不同的阶段合并到不同环境对应的分支上，对功能需求进行测试、验收以及上线。当开发团队规模较小的时候，使用Git Workflow无疑是相对适合的，优点是相对灵活。但是当团队人数达到一定程度，项目较多之后，这种工作流就会暴露本身的局限性，权限管理比较混乱。这个时候，Forking Workflow就应运而生了。什么是Forking Workflow？Forking Workflow就是存在一个主仓，其他开发人员把主仓Fork一份到自己的仓库中，然后在自己的仓库中进行功能开发，开发完成后提交Merge Request，然后团队Review，确认没问题之后进行合并更新操作。相比Git Workflow，Forking Workflow可以更好地管理主仓代码，保证主仓代码的安全、一致性等，且可以杜绝分支过多引发的其他问题。
怎么创建Merge Request
言归正传，让我们看看怎么创建
MR。在我朋友圈中有大L和小L两位小伙伴，分别使用Git Workflow和Forking Workflow两种不同的Git工作流。中国传统敬老爱幼，那么就由使用Forking Workflow的小L为我们演示一下怎么创建一个MR。
Forking Workflow
此时使用
Forking Workflow的小L同学接到一个需求，小L思路清晰，他首先查看主仓（awesome-php名下的awesome-one仓库，下文一律使用主仓称呼），然后基于主仓Fork一个属于自己的仓库：
此时小L个人（也就是
zmcdbp）名下也有了一个awesome-one仓库，小L接着要做的事自然就是Clone自己的仓库到本地：
突然接到的需求需要开发一个
phpinfo页面，遵循Forking Workflow规范的小L的做法是先基于本地的master分支衍生一个feature-phpinfo的功能分支，然后在该分支上进行开发，开发完成后添加更改的代码到缓存区，提交commit：
完成本地提交之后，接下来要进行远程分支的提交，小L提交到了自己名下的仓库中（也就是
zmcdbp/aweosme-one），分支名称与本地分支保持同步，方便日后翻阅查找（此处因为小L名下的awesome-one仓库中尚未存在feature-phpinfo分支，所以在push操作的时候需要带上-u参数告诉GitLab需要创建一个名叫feature-phpinfo的远程分支）：
push成功之后小L选择了回到GitLab Web中查看刚刚提交了更新的仓库：
小L很开心，因为发现他名下的
awesome-one仓库 中已经多了一个远程分支feature-phpinfo。接下来小L要把这个已经开发好的功能分支合并到主仓中以便后续进行功能测试以及产品验收等步骤。首先小L创建了一个MR（因为本地分支是推送到了小L从主仓中Fork出来的个人仓库中，所以创建MR的动作也应该在自己仓库的GitLab Web页面中进行）：
创建
MR的页面信息量相当大，懒癌晚期的小L选择了只关注Title、Description、Source branch、Target branch以及Remove source branch when merge request is accept这几项，如果你比较勤快当然也可以对其他配置项进行详细配置。懒癌晚期的小L关注的这几项配置都是什么呢？Title当然就是本次MR的简要说明，Description自然就是详细说明，里面可以填写本次合并主要功能以及相关负责人员等（支持Markdown噢！），Source branch英语超赞的你肯定已经猜到这个就是我们要发起合并的分支，Target branch自然就是接受合并的分支啦，Remove...说的就是当本次MR被接受之后，自动删除发起合并的分支，是不是超贴心！小L对自己比较关注的几项配置进行简单填写后，点击下方的提交按钮，创建MR的操作就完成啦！连懒癌晚期的小L都能轻松创建，是不是超简单！
但是聪明的你肯定发现了事情似乎并没有这么简单！
Target branch默认是master分支并且似乎无法更改，那么如果需要合并到其他如dev分支的话该怎么办呢？没关系，点击Target branch旁边的Change branches就可以对Source branch和Target branch进行更改啦！（合并请求不单单可以向主仓发起，还可以对自己仓库内存在的两个分支进行发起，或者对主仓派生的其他仓库中的分支发起）
在
Forking Workflow中一个MR的诞生差不多需要经历的就这么多，当然还有更多细节由于篇幅问题没有一一细说，还请见谅。
Git Workflow
组织把比较重要的
hello world需求留给了我们成熟稳重使用Git Workflow的大L同学，大L不假思索地访问了主仓的页面并进行了Clone操作，然后在本地创建了一个需要进行功能开发的feature-hello-world分支。注意，大L是从主仓Clone，而小L是从自己Fork出来的仓库Clone。
接着大L迅速完成了开发工作，与小L的本地提交操作类似，把更改的文件添加到缓存区，然后添加
commit。
完成了本地提交后，大L选择了把新开发的功能分支推送到远程仓库中。（与小L类似，因为远程仓库中尚未存在与本地同名的分支，所以需要添加
-u参数创建远程分支）
完成推送到远程仓库的操作后，大L打开了主仓的页面然后点击旁边出现的
Create Merge Request按钮来创建一个MR。进入到创建页面之后，大L的操作就跟小L点击创建MR按钮后的操作一致了，在这就不再重复了。（都是姓L的，一样的姓，一样的病【懒癌晚期】）
Ending
通过大L和小L的日常工作相信聪明的你已经了解了两种工作流都要怎么创建
MR了吧。MR是个好东西，如果拥有一套成熟的流程体系的话。缺点的话，当然就是有点一板一眼的，不是那么灵活，但是换来的是规范化以及流程化。这篇文章到这就结束啦，感谢大家的阅读。希望大家能从这篇文章中得到帮助。如果你对这篇文章有任何意见或建议，都欢迎给我发送邮件，优质的文章离不开读者的反馈。