目录
分支合并，应该可以说无论是做什么项目都会涉及得到，即便是个人在负责整个项目也是需要用到的。Git分支合并有两种：快速合并和三方合并。通过上一节Git架构浅谈所说的分支可以理解为是一条时间节点的时间线，分支的指针始终指向最后一个时间节点（提交点），那么分支合并时，分支的各自指针又是怎么指向的呢？
一、合并指令
无论是快速合并还是三方合并，都是一样的指令：git merge xxxx(分支名)
二、快速合并
假设目前有两条分支：分支A和分支B，分支B是从分支A最后一个节点创建的，此时分支B做了一次commit提交，原来的分支A并没有做任何改动和commit提交，这是分支A要把分支B最新提交的内容进行合并，这种合并就叫快速合并。
下面我们来看看快速合并的分支指针指向是如何的，通过命令git log --oneline --graph指令观察：
这样进行观察，我们可以断定快速合并，只是将master分支指针指向了dev分支最新的提交点：
三、三方合并
在多人协同开发时，我们不敢保证新的分支dev创建出来后，原来的master分支不会被修改并提交，这时候Git是没法做到快速合并的，并非只是简单移动master分支指针指向那么简单。具体是怎么指向，下面通过实例说明下：
（1）首先我们分别对master分支和dev分支进行修改同一个文件a.txt，并分别对两个进行一次提交commit：
（2）在master分支上与dev分支进行合并，这时候就并没有出现快速合并的提示了，其实git已经默认以三方合并的方式进行合并：
（3）三方合并分支走向如下，Git会将节点1、节点2（master最新节点）和节点3（dev最新节点）进行合并，合并之后会在master分支上再创建一个新的时间节点，此时合并后的master分支指针就指向该合并后的新节点
四、解决冲突
假设不同分支同一个文件都被做了修改和提交，然后再合并，类似刚才的三方合并，这样文件内容会是怎么样的呢？难道在不同分支做了不同修改，Git会知道我们最终以哪个分支的修改作为最新标准？当然不是啦！哪有那么智能，Git只会保留两个分支的内容，也就是Git会认为这个文件两者产生了分歧，也就是所说的冲突，然后让做出修改的两个程序员，坐下来喝杯茶，好好商量决定留谁的修改作为最终标准。
假设商量成功后决定保留dev分支改动后，即可删除一连串等号（包括等号）以上的内容，和一连串>的内容，当然这一步对比操作，可以通过Git可视化（乌龟）界面进行对比修改，鄙人比较懒不愿意一个个找哪些文件都被修改产生冲突，惯用的一个技巧是，是直接通过软件程序进行编译，一般是编译不过的，我们即可根据编译不过的地方进行修改，然后根据提示需要再进行一次提交（生成最终合并后的时间节点）。
