理解核心
Git最初只有一个分支，所有后续分支都是直接或间接的从这个分支切出来的。
在任意两个分支上，向前追溯提交记录，都能找到一个最近的提交同时属于这两个分支，这个提交就是两个分支的分叉节点
分支合并，就是把其它分支相对于分叉节点发生的变化合并到当前分支中。
Git合并(merge)的是变化！
假设情景
时间点1：两个分支master和dev，现在这两个分支完全一样，处在同一个提交(commit)上，内容含A、B、C、D四部分。
时间点2：dev上开发新内容，不断修改提交，最后dev分支的内容是A、b‘、D、E。修改B为b‘，删除内容C，新增内容E。
时间点3：master分支发现bug，在该分支修改bug并提交，最后master分支内容是A、b‘‘、c、F。修改内容B为b‘‘，修改内容C为c，删除内容D，新增内容F。
时间点4：此时，如果把master分支合并到dev分支上，master和dev上的内容是什么呢？
合并过程
git checkout dev # 切换到dev分支 git merge master # 合并master分支
合并merge做的几件事儿：
1、在dev上删除D，新增F。
这是master分支在时间点3上相对于时间点1发生的部分变化，D在dev分支上没有变化过，F相对于dev是新内容，合并时没有冲突，可直接合并。
2、C上产生冲突，该冲突是"修改、删除"两种不同动作引起的。
时间点2上dev删除了C，时间点3上master修改了C，删除和修改的对象都是同一个C。相对于时间点1，产生了不一致的变化，无法直接合并。
3、B上产生冲突，该冲突是内容变化后不一致引起的。
时间点2上dev修改B为b‘，时间点3上master修改B为b‘‘，修改后B内容不一致。相对于时间点1，也是产生了不一致的变化，无法直接合并。
merge遇到无法合并的冲突(conflict)时，会先记录下冲突信息，然后跳过冲突继续合并后面的内容，直至合并完所有可以合并的内容后，只剩下无法合并的冲突。此时，merge再也无法继续执行了，只能被迫中断。中断前merge做了最后一件事儿，就是在dev分支上标识出冲突信息，提示用户需要解决冲突，然后再自行完成merge后面的操作——提交合并后的新commit到版本库。
如果合并过程顺利，是不会产生冲突的，merge就可以在合并完成后，自行提交新commit到版本库。
这种合并方式是真实的合并(TRUE MERGE)，合并后会在dev分支上产生一个新的commit。还有一种合并方式是快进合并(FAST-FORWARD MERGE)，这种方式不会产生新的commit。
解决冲突
1、删除C
2、修改B为正确内容b‘‘‘
3、解决冲突后，提交一个新的commit
至此，分支内容如下：
master：A、b‘‘、c、F（master是被合并的，所以自己的内容不会变化）
dev：A、b‘‘‘、E、F（合并了master在时间点3上相对于时间点1发生的所有变化，并解决了冲突，生产了新commit）