如果你仔细，很有观察力，你可能已经发现我在上述说明中存在的一个漏洞了：由于commit提交 A和B可能各自又包含commit,他们最近的共同祖先可能不是唯一的！一般，他们最有可能的情形是，最近的共同祖先是 C1,C2,C3,C4,⋯Ck−1,Ck ，在这种情况下，git merge 操作将会递归的执行：它首先构造合并 C=C1∨C2∨C3⋯Ck−1∨Ck ，并以此作为三向合并[ A ]+[ B ]−[ C ] 的基础（base）。这就是为什么Git的默认合并策略并称为递归的。 假定两个分支如下图所示，A,B,C,D,E是master分支的历史快照（snapshot）;A,B,X,Y,Z是feature分子的历史快照。
命令
git merge feature
首先查找“master”（当前分支）和“feature”的共同祖先。它或多或少的等价于以下命令：
git merge-base master feature
在我们的举的例子里，他们的共同祖先是B。 如果在C,D,E和X,Y,Z提交中没有冲突，git 将会创建一次“merge commit ” merge commit会有两到多个父亲。 新的图将会是下面这个样子。
每一次git commit 提交都会生成一棵树，一到多个“父亲节点”，作者的名字，email,日期和提交者的姓名，email,日期。merge提交和普通的提交的唯一区别就是祖先的数量。
在第二幅图中，merge commit提交被以M标注出来了。 如果提交存在冲突，用户就会被要求解决冲突，并手动创建合并提交，在冲突解决后
git commit -a
将会创建合并提交。这条命令没什么特殊的语法。Git 已经知道了用户已经在进行合并了（已经在尝试合并）。