GitLab轻松创建一个Merge Request

简写说明

- 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 按钮后的操作一致了，在这就不再重复了。