git 分支合并 3 way merge

一、

• 如下图，master 分支的最近一次 commit 是 C2，此时我们创建一个新分支：bugfix，bugfix 分支的最近一次 commit 是 C3。
• 此时，这便是所谓的 fast-forward 合并；只需要切换到 master 分支，然后在 master 分支执行命令 git merge bugfix 即可。
  
• 如下图，如果此时 master 分支指向的 commit 变化了，指向了 commit：C4，此时 bugfix 分支与 master 分支就不属于 “fast-forward”合并的情况了，而是所谓的“3 way merge”。
• 此时如果在 master 分支上执行命令 git merge bugfix 会发生什么情况呢？
  

---

二、演示

• 首先在 master 分支上，提交一个文件 test.txt。

• 切换到 bugfix 分支，修改文件 test.txt。

• 再切换回 master 分支，也是对同一个文件 test.txt 做修改。

• 此时，在 master 分支上可见的两个 commit 分别是 1st 和 3rd。

• 再切换回 bugfix 分支，bugfix 分支的 commit 分别是 1st 和 2nd。

• 在“ 3 way merge”状态下，由于多个分支修改了同一个文件，所以 merge 合并需要解决冲突。

• 此时在查看暂存区，可以看到三个不同的 test.txt 文件。
• 可以看到，这三个文件分别对应合并前的原始内容，以及 master 分支和 bugfix 分支分别修改的内容。
• 最后我们通过 vim 修改文件内容，将 master 分支和 bugfix 分支的修改全都采纳。

• 解决冲突之后，还需要执行一次 commit 提交，将我们解决冲突的方案提交到 git 版本库。

• 分支合并后的commit，它会有两个 parent。
• 一个 parent 指向 bugfix 分支最近的一次 commit。
• 一个 parent 指向 master 分支合并之前的最近一次 commit。

---

三、如果没有发生合并冲突

• 如果合并的时候，没有发生修改同一个文件导致的“合并冲突”，git 就会自动帮我们将这次合并 commit 到 git 版本库中，无需做其他操作。
• 可以看到，并没有出现上面第二段所谓的 “master | MERGING”状态。

• 合并操作后，依然是最新的 commit 存在着两个 parent 提交。