Git 分支合并

理解核心

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）