上一篇讲了remote相关，让大家基本了解了一下远端库与本地库之间的联系。目前我认为还剩下的容易造成理解混乱的是merge命令以及merge动作的应用场景，下面详述。
首先先给大家解释merge本身的一些内容，再结合一些场景帮大家从混乱的理解中找到思路，进而完全理解Merge Request的意思并掌握这项技能。
merge译成中文是合并，顾名思义，git merge命令时用来合并的，而合并的对象就是branch（分支）。下面我举个简单的应用场景（只在本地Repository中）来说明：本地库中有两个分支testBranch1和testBranch2。目前两个分支中的文件内容相同，都只有一个fileA.txt文件，而且fileA.txt的内容只有一行文字：HelloWorld!
如果你目前处于testBranch1，并且修改了fileA.txt文件在第二行增加了一句：Hello!
此时你的fileA.txt形如：
HelloWorld!
Hello!
不仅如此，你还新建了另一个空文件fileB.txt，并且把所有的修改commit进来。
然后checkout到testBranch2上，此时testBranch2上应该只有一个fileA.txt文件而且内容只有一行HelloWorld!此时你又修改了fileA.txt在第二行增加了一句HaHa! ，并且把所有的修改都commit进来。
此时你的fileA.txt形如：
HelloWorld!
HaHa!
现在可以想象，testBranch1和testBranch2两个分支分别管理着两套不同版本的内容了。前者有两个文件，后者只有一个文件，而且名字相同的文件内容也有所差别。好了git merge命令马上要出场了，下面请特别注意小编介绍的两个场景：
场景1：
git checkout testBranch1 （即切换到testBranch1分支上），执行git merge testBranch2命令。这样代表：站在testBranch1分支上，把testBranch2分支上的内容融合到testBranch1分支上来。
这样git会尝试把testBranch2中的内容与testBranch1融合，而这样是不会改变testBranch2分支上的内容的，只会改变testBranch1上的内容。所以此后testBranch1上有两个文件（fileA.txt和fileB.txt），而testBranch2上依然只有1个文件（filtA.txt）
场景2：
git checkout testBranch2 (即切换到testBranch2分支上)，执行git merge testBranch1命令。这样代表站在testBranch2分支上，把testBranch1分支上的内容融合到testBranch2分支上来。
这样git会尝试把testBranch1中的内容与testBranch2融合，而这样是不会改变testBranch1分支上的内容的，只会改变testBranch2上的内容。所以此后testBranch1上有两个文件（fileA.txt和fileB.txt），而testBranch2上也有了2个文件（fileA.txt和fileB.txt）
场景1和场景2在整体上的变化大家明白以后应该就能理解merge命令的含义了吧？下面说一下另一个细节
相信大家注意到，如果第一个分支的fileA.txt和第二个分支的fileA.txt进行融合的话，是有可能产生歧义的。前者的第二行希望是Hello!，后者的第二行希望是HaHa!那么最终结果到底听谁的呢？这种情况下Git就“有可能产生冲突”。那么在merge过程中产生冲突是怎样的效果呢？此时你的fileA.txt可能会呈现类似以下的中间状态（此时以场景1的情况为例）：
HelloWorld!
>>>>>>>>>
Hello!
=========
Haha!
<<<<<<<<<
类似这样的状态代表Git说：我糊涂了。就需要我们人工来解决这样的冲突。此时我们可以打开fileA.txt文件，发现内容可能如上所示。解决时我们会想：Hello!是我在操作testBranch1时想加的话，HaHa!是我在操作testBranch2是想加的话。两个我都想保存下来，那稍微编辑一下就想搞成如下形式：
HelloWorld!
Hello!
HaHa!
这样解决冲突（即人为编辑）完成后我们保存并关闭文件。
注意！此时我们仍然处于merge的“过程中”，要想完成merge必须告诉Git：刚才冲突的文件就按照我刚才保存的这样解决！怎么告诉Git呢？就是git add fileA.txt然后git commit -m "解决fileA文件的冲突问题"两个命令。说白了就是再把最新的fileA.txt文件加入Git的管理。
这些都做完之后，我们就已经渡过了merge过程回家包饺子了。
这里需要理解一个Git的底层原理，这里称其为原理111：在将testBranch2分支merge到testBranch1分支中时，我们像上面那样解决fileA.txt文件的冲突。这样Git就“知道了”上面这个冲突的解决办法，即用形如：
HelloWorld!
Hello!
HaHa!
的内容来替换冲突文件中的内容（因为这是刚才主人决定的）。那么如果此后再将testBranch1分支merge到testBranch2分支中时，我们就不必要再手动解决冲突了，因为Git已经知道该怎么做了。
这个原理会在后面的remote中得到应用，，所以希望读者在此能够理解到位。
好了分割线=====================================================================================================================
下面就来讲解一下什么是Merge Request以及怎么进行合理的Merge Request
举一个比较简单的场景：
你们公司的服务器是Stash，上面有个正在开发的项目：ComRepository。这个项目有三个分支：master，worker1，worker2。那么如果把这个项目clone下来之后，本地也会有三个分支：master, worker1, worker2。现在心里要清楚哦，如小编第一篇文章所说，你所知道的是有6个分支的哦，服务器上3个，你本地3个。而对于公司来说，他们不在乎每个员工本地的分支是怎样，他们只在乎服务器上的master分支是否运转正常。因为服务器上的master分支有可能就是公司发表项目时用的分支，所以这个分支上的代码至关重要！
此时公司要求你就在worker1分支上开发吧！那么你的开发流程是什么呢？总之最终目的是要让服务器上的master分支有你开发好的代码。
为了方便，后面依然把本地分支带上后缀（L），如worker1（L）。
一种思路：
在worker1(L)分支上开发，然后checkout到master(L)上，将worker1(L)分支merge到master(L)上来，然后将master(L)的新代码push到服务器的master上去。
这种思路是不该推荐的，如果我是老大，我是不会给你分配master分支的push权限的。因为这样太危险了，master分支是公司至关重要的分支，岂能让你说push就push？这样会让公司的master上的代码时刻处于危险之中。
第二种思路：
每一个成功者都有一个开始。勇于开始，才能找到成功的路。
