关于第二点，您是正确的，git保存快照。然而，给定任何两个快照a和b，我们可以通过比较b与a来得到一个变更集（差异）- git会根据需要执行此操作。
至于合并本身，首先，我们必须注意git保留提交图（也称为“DAG”或“提交DAG”，因为该图是有向无环图或DAG）。这就是您的git log --graph输出所显示的，尽管在这种特殊情况下，我们具有如此简单的图形形式，以至于它只是一棵树（直到合并被提交为止）。
对于任何树结构以及许多DAGs，1给定树中的两个节点，我们可以找到唯一的LCA（最低公共祖先）节点。这里的两个节点是两个分支的末端 - 提交cf3456b（当前分支的末端）和81e6490（master的末端），而在这种特殊情况下，LCA是第一个提交c667d3b。在像这样的简单情况下，LCA很容易在视觉上发现：您只需查看提交图以查找两个分支加入的位置（从那里开始，一直回到根，都在两个分支上）。
此LCA节点是合并基础。 Git首先找到当前提交和您给出的参数的合并基础。（对于“章鱼合并”，其中您指示git将多个提交合并到当前分支，该工作有点更复杂，但我们可以在这里不予考虑。）
接下来，鉴于现有的合并基础和两个不同的末端提交，git必须计算两个变更集：一个从合并基础到当前提交，另一个从合并基础到参数提交。请注意，git在整个过程中仅执行一次此操作，之后即可继续合并操作。
现在，对于每个存在更改的文件，git必须组合更改。 对于大多数简单的修改，方法很简单：如果文件1只在一个分支中进行了修改，请将修改按原样采取。 如果它在两个分支中都被修改，请尝试组合修改，在两个分支都进行相同更改的地方只使用一个副本。当然，如果两个分支对单个文件的相同区域进行了不同的更改，则会发生冲突。
对于文件创建或删除的情况，或者存在重命名的情况，这些情况就有点棘手了。如果在一个分支中删除了一个文件而在另一个分支中没有改动，则 git 可以通过删除文件来解决这个冲突（如果它已经在 HEAD 中被删除，就“保持删除”，如果它在另一个提交中被删除，就将其删除）。如果在一个分支中对文件进行了重命名并在另一个分支中进行了修改，则 git 也可以组合这些更改（同时进行或保留重命名，并且导入或保留其他更改）。然而，对于其他的绝大多数情况，git 只会声明冲突，放弃并让你解决冲突。
在这种情况下，文件 1 确实在当前分支中被修改了，在 master 中也确实被删除了。Git 不确定是要删除该文件（根据与 merge-base 到 master 的 diff 指示），还是要保留更改（根据与 merge-base 到 HEAD 的 diff 指示），因此它让你处理这个文件和冲突。
如果你在两个分支中都创建了一个新文件 5，git 会再次给你一个冲突（除非在两个分支中新文件的内容相同——我没有测试过这种情况）。
1对于复杂的 DAG，可能有多个最低公共祖先候选者。对于 git 的“递归合并”，git 通过合并每个 LCA 候选者来形成一个新的“虚拟基础”。这个虚拟基础成为两个提交进行比较的 merge-base。如果只有两个 LCA 候选者，则可以通过大致相当于以下操作来获得虚拟合并基础：
git checkout -b temp candidate_1
git merge candidate_2
git commit -a -m ""
在这个“内部合并”过程中发生的任何合并冲突都会被忽略：带有冲突的合并基础将被使用。这可能会导致一些看起来很奇怪的冲突，尤其是当在“外部”合并的同一区域发生冲突时：请参见
此 SO 问题。
如果存在两个以上的LCA候选项，则
merge-recursive将取前两个进行合并，然后合并第三个，然后合并第四个，依此类推。尽管它可以合并成对减少数量，然后再合并合并对以再次减少数量，以此类推，但它仍然执行上述操作。也就是说，对于给定的N个LCA候选项，可以进行ceil(log2(N))次合并，而不是N-1次合并，但是git很少使用N超过2。
