Git Merge 的内部流程

首先要说明的一点是, Git 本身有一套内部的合并系统, 而不是通过外部比较工具来进行代码合并. 但是可以通过给 git merge 命令添加 -s 选项来指定合并策略(resolve, recursive, octopus, ours, subtree):

-s <strategy>
--strategy=<strategy>

本质上来说, 在 Git 中, 每个 merge 都会被视为冲突, 冲突内含有一个索引, 该索引内的每个文件保留三个版本: 当前分支, 合并分支, 基础分支. 然后, 各种的 Resolver 就会在这个索引上开始执行了, 这些 Resolver 将会针对每个独立的文件来解决冲突.

第一阶段是 trivial resolver, 它会负责一些无关紧要的工作, 比如: 未修改的文件, 仅有一个分支存在改动的文件, 两个分支都包含相同新版本的文件.

接下来, 插件会开始处理剩下的情况. 有负责处理文本文件的插件, 它会识别一个分支内的个体改动(比如: diff ), 并将那些改动应用到另一个分支上, 如果没有成功则放置一个冲突标记. 同样, 此时也可以很容易的在合并工具内进行回调处理, 打个比方: 可以开发一个工具, 用来合并 XML 文件而不违反语法规则, 或者提供一个支持交互式编辑的图形用户接口和一个并排式的视图(例如: kdiff3).

因此, 冲突的产生取决于所使用的插件; 文本文件的默认的插件与 CVS 会使用相同样式, 因为大家已经习惯这种形式了, 并且冲突标记几乎在任何编程语言内都会被视为语法错误.

参考

07 Feb 2011 ▸ What constitutes a merge conflict in Git?