Git合并

aaahd

　　一次合并会结合两个或多个历史提交分支。尽管Git还支持同时合并三个，四个或多个分支，但是大多数情况下，一次合并只结合两个分支。
　　在Git中，合并必须发生在一个版本库中------也就是说，所有要进行合并的分支必须在同一个版本库中。版本库中的分支怎么来的并不重要。
　　当一个分支中的修改与另一个分支中的修改不发生冲突的时候，Git会自动计算合并结果，并创建一个新的提交来表标识新的统一状态。
　　但是当分支冲突时，Git并不解决冲突，所以，当Git无法自动合并时，需要在所有冲突都被认为解决后做一次最终提交。
　　1，一个最简单的合并的例子

　　创建一个新的版本库，新建文件"file"，添加图片中的内容。然后提交到版本库。

　　ok，在当前分支 master 下继续添加文件”other_file“，添加图片中的内容，并提交到版本库中。

　　至此，版本库里已经有一个包含连词提交的分支 master，每次提交引入都引入了一个新文件。接下来，新建并切换到不同的分支。

　　新的分支>

　　现在就有了两条分支，两条分支都开始了自己的工作，都针对文件”file“进行了修改，因为这两个修改并不影响相同文件的相同部分，所以合并应该会顺利进行，不会发生事务。

　　git merge 操作是区分上下文的。当前分支始终是目标分支，其他一个或多个分支之中是被合并到当前分支。现在想要>

　　nice，合并顺利进行，两个分支对文件”file“的修改顺利的合并在一起。然后来看看提交历史：

　　两个分支在 53d24be 这个提交处分开（当时的 master 是提交了other file，所以分支基于的 master^ 就是"init 3 line in file"这个提交），分支修改了文件”file“，产生了一个提交 4a547440。最后执行提交产生一个新的提交 475e5e8 。
　　可以看出，Git执行合并的操作都会产生一个合并后的提交，并添加到当前分支中，而被合并分支不受合并的影响。
　　2，有冲突的合并
　　不废话，直接来实际的操作。首先在 master 分支上，继续修改文件“file”，然后提交到版本库

　　然后，切换到>

　　继续，检出 master 分支并尝试着进行合并

　　Git已经提示我们了：合并的时候在文件“file”检测到冲突，自动合并失败，解决冲突后才能提交。一旦遇到冲突，一定要使用 git diff 命令来查看一下冲突的程度

　　结果显示了 工作区 和 暂存区 之间的差异。
　　在传统的 UNIX/Linux 系统中 diff 命令的输出风格里，改变的内容显示在<<<<<<<和=======之间；替代的内容在=======和>>>>>>>之间。
　　在解决合并冲突时，根据实际工作情况自己选择任何解决方案。包括只取一边或另一边的版本，或者两边的混合，甚至是全新的内容。
　　ok，开始手动解决冲突，解决后。文件“file”的内容如图，如果对冲突解决很满意，那么就应该 git add 命令，为合并提交而暂存之。

　　Git的提示已经很明显了：冲突已解决，但是依然处于合并状态（当前的分支为 master | MERGING），使用 git commit 命令来结束掉本次合并。执行 git commit 命令，Git会进入到vim编辑器中，并准备了一条模板消息。ok，搞定！
　　深入处理合并冲突
　　重新初始化一个版本库，创建一个文件“hello”，内容为“hello”，提交到版本库中

　　创建一个名为>

　　切回到 master 分支，此时文件”hello“的内容为 hello，在末尾追加 worlds，并提交大版本库

　　此时，hello的内容，master 分为 hello worlds，alt 分支为 hello world。尝试合并>　　1，Git提示我们有未完成的合并。
　　2，建议我们解决冲突后运行 git commit 命令，又或者可以执行 git merge --abort 命令来取消本次合并。
　　3，Git提示我们冲突发生在 hello 这个文件里。

　　现在，使用 git diff 命令来检查冲突的细节：

　　这里的>

　　在较新版本的Git中，git diff --ours 是 git diff HEAD 的同义词，--ours 更好理解。同样，git diff MERGE_HEAD 可以写成 git diff --theirs。
　　在解决冲突的过程中，可以使用一些特殊的 git log 选项来帮助我们寻找出变更的确切来源和原因：git log --merge --left-right -p <file|path>，git log 的选项如下
　　--merge：只显示根产生冲突的文件相关的提交。
　　--left-right：如果提交来自合并的”左边“则显示<（”我们的“版本，当前分支的版本），如果提交来自由合并的”右边“则显示>（”它们的“版本，目标分支的版本）
　　-p：显示提交消息和每个提交相关联的补丁。
　　<file|path>：如果版本库很复杂，且冲突的文件很多，可以指定确切的路径或文件。

　　可以看到，输出的信息还是很多的。有一种手段可以缓解来自大合并中繁多的冲突的痛苦：那就是定义良好的小提交。Git对小规模提交处理的很好，因此没有必要等到最后才提交一个又庞大又影响广泛的修改。小规模的提交和更频繁的合并周期可以减少解决冲突的痛苦。
　　那么，Git是如何追踪冲突的呢？
　　主要有以下几个部分：
　　1，.git/MERGE_HEAD，任何使用提到 MERGE_HEAD，Git都知道去查看哪个文件。
　　2，.git/MERGE_MSG，包含当前解决冲突后执行 git commit 命令是用到的日志消息。
　　3，Git的索引项包含每个冲突文件的三个副本：合并基础，”我们的“版本 和 ”他们的“版本，分别给这三个副本分配各自的编号 1，2，3。
　　4，冲突的版本不保存在暂存区。只保存在工作区。
　　查看Git索引项是如何存储的，可以使用 git ls-files 底层。如果指向查看根冲突相关的文件，可以使用 -u 选项

　　可以看出，hello 文件存储了三次，用前面说过的 git cat-file -p 命令来查看各个版本的内容

　　更可以使用 git diff 来比较两个指定版本之间有什么区别

　　了解了Git是如何追踪冲突之后，就可以很淡定的处理冲突了。

　　这里执行 git add 命令是把索引项重写，只有一份 hello 的副本。
　　必须解决索引中记录的所有冲突文件。只要有未解决的冲突，就不能提交。因此，当解决一个文件的冲突之后，执行 git add（或者 git rm，git-update-index等）以清除它的冲突状态。
　　注意：不要对有冲突标记的文件执行 git add命令。虽然会清楚索引中的冲突，并允许提交，但是文件内容将是错误的。
　　最终，执行 git commit 命令，解决冲突过程中产生的 .git/MERGE_HEAD .git/MERGE_MSG 都会被Git删除。