第16章　冲突解决

16.1　拉回操作中的合并

（3）用户user1执行拉回操作的第二阶段，将本地分支master和共享版本库本地跟踪分支origin/master进行合并操作，如图16-3所示。

图　16-3　执行合并操作

（4）用户user1执行推送操作，将本地提交推送到共享版本库中，如图16-4所示。

图　16-4　执行推送操作

实际上拉回操作（git pull）是由两个步骤组成的：一个是获取操作（git fetch），另一个是合并操作（git merge），即：

git pull=git fetch+git merge

图16-2示意的获取操作看似很简单，实际上要到第19章介绍远程版本库的章节才能够讲明白，现在只需要根据图示将获取操作理解为将远程的共享版本库的对象（提交、里程碑、分支等）复制到本地即可。

合并操作是本章要介绍的重点。合并操作可以由拉回操作（git pull）隐式地执行，将其他版本库的提交和本地版本库的提交进行合并。还可以针对本版本库中的其他分支（将在第18章中介绍）进行显示的合并操作，将其他分支的提交和当前分支的提交进行合并。

合并操作的命令行格式如下：

git merge[选项…]＜commit＞…

合并操作的大多数情况，只须提供一个＜commit＞（提交ID或对应的引用：分支、里程碑等）作为参数。合并操作将＜commit＞对应的目录树和当前工作分支的目录树的内容进行合并，合并后的提交以当前分支的提交作为第一个父提交，以＜commit＞为第二个父提交。合并操作还支持将多个＜commit＞代表的分支和当前分支进行合并，过程类似。

默认情况下，合并后的结果会自动提交，但是如果提供—no-commit选项，则合并后的结果会放入暂存区，用户可以对合并结果进行检查、更改，然后手动提交。

合并操作并非总会成功，因为合并的不同提交可能同时修改了同一文件相同区域的内容，导致冲突。冲突会造成合并操作的中断，冲突的文件被标识，用户可以对标识为冲突的文件进行冲突解决操作，然后更新暂存区，再提交，最终完成合并操作。

根据合并操作是否遇到冲突，以及不同的冲突类型，可以分为以下几种情况：成功的自动合并、逻辑冲突、真正的冲突和树冲突。下面分别予以介绍。