merging
有时合并导致冲突。通常它们很容易解决，但你需要解决它们否则你的仓库将会有多个头。谁又想要多个头呢？
版本控制一个非常重要的组成部分是在同一个代码库中进行多人协同工作。
想象一下Rose和我都想对果酱食谱进行修改。Rose提高了牛油果的品质。在她开始工作前，她将从中央仓库拉取所有的最新变动，以便自己在最新版本上工作。
现在看下编辑情况：
她提交并且推送这一变化到中央仓库：
同时，我在这一文件的不同的地方做了一些更改：
我能够提交，但是我不能够推送到中央仓库。
这也许是在水银中最没有用的错误信息，它应该这样说：
事实，那正是我将要做的：
好奇刚刚来了什么？输入** hg log -P**。这一命令可以帮助你方便地查看。
事实上，那是Rose较早的改动，我的仓库现在该怎么办呢？
我有“多个头”。本质上，我的仓库看起来如下：
看到两个头了吗？这是因为Rose的改动是基于变更集7的，而我的改动也是基于变更集7的。所以现在有必要进行合并。（千万不要忽略它）
合并命令，hg merge，合并两个头，并将结果保存在我的工作目录，它没有提交，这给了一个机会让我来检查合并是否正确：
这看起来是对的，鳄梨是Hass，辣椒是胡椒，所以我将继续下一步，将其推送到服务器。
我推送了两个变更集：我原来的墨西哥胡椒变更，和之后的合并，这是它自己的变更集。
注意我俩各自的变更之间没有冲突。因为我和Rose在修改配方的不同部分。所以合并非常容易。这是最常见的情况，因为在大多数组织中，每个程序员被分配在不同的代码段进行工作。
但是，即便是管理再好的、健康的组织，合并冲突时有发生，这时水银会要求人为地来解决这些冲突。让我们看看那是什么样子的。
首先......我想要让Rose的把我的变更集给拉下来：
现在，我们来看下将要发生什么，当有一些冲突，我们都要修改一下配料。
我添加了一个香蕉：
我先检查下香蕉的变化：
而Rose，在完全相同的一行添加了一个芒果。
确切地说是“ripe young mango”。
这次我先上传了我的变更，所以Rose必须进行合并。哈！
忽然，冲突被检测到，并弹出一些合并冲突的解决工具，是不太友好的界面，但是他们通常是非好好用的，你能想到的功能都有。一个常见的合并冲突解决工具是 KDiff3, 如下：
在KDiff3中，你能看到4块窗口，左上角是原始文件，上面中间部分显示Rose的版本，右上方显示我的版本。下面的窗口中是一个编辑器，Rose在这里解决冲突并构建出合并的文件。
修改冲突是一个相对简单的问题，要做的是遍历每一个冲突并且做一个选择题。Rose决定用香蕉芒果酱。
Rose保存了她的改动并且退出了KDiff3。
冲突解决了。
有一件事你要牢记：你不必按照任何人的时刻表去合并。你在任何时候都可以使用hg pull，如果你不想要合并冲突，你完全可以继续工作，然后愉快地提交。等到你什么时候想合并了，你再合并。
自测
以下是你读完本篇教程应当会做的事：
- 与他人在相同的代码块上工作。
- 获得他人的变更。
- 推送你自己的变更。
- 解决合并冲突。
