分布式版本控制软件水银（Mercurial）使用指南2

Setting Up for a Team

翻译自：http://hginit.com/02.html

使用水银的好处之一是可以使一个团队协同工作。水银使得你们可以单独地工作，然后把你们的更改合并到一起。
使用水银来协同工作的最普遍的方法就是在我们的个人计算机之外，再建立一个中央仓库。我们可以把中央仓库作为一个交换区，从而来得知大家都作了哪些更改。

图1

建立中央仓库的最简单粗暴的办法就是在服务器上，用 hg init命令。并且使用 hg serve命令使之成为web服务端。默认地，该服务的端口号为8000.

图2

由于这台电脑的名字叫做joel.example.com，因此可以通过网址http://joel.example.com:8000/来登录。

图3

中央web服务端运行之后，我就可以从将这个仓库从服务器端拷贝到我的电脑上为我所用了。这个仓库现在是空着的，因此我也只拷贝到了空的仓库。

图4

现在我要建立一个叫做 guac的文件。

图5

我添加这个文件，然后提交，以作为第一个官方版本。

图6

我会提供一个提交注释：

图7

我快快地做些许改变，使得我们的仓库也有些历史：

图8

现在提交变更：

图9

看，我提交的时候用了 -m这个参数。这是在命令行直接写提交信息的方法。

OK。现在我们到哪里了呢？我们建立了中心仓库，并且复制到了本地电脑上。然后做了两个变更并且提交了。然而那些变更只是在我的本机上——它们还没有出现于中心仓库呢。因此，现在水银的世界看上去是这样的：

图10

现在，我们要使用 hg push这个命令，来把我的变更推到中心仓库中：

图11

很好。然而似乎不行。这里有一个安全性的考量，看看是不是要让全世界的人都可以把它们的变更推送到中心仓库中。可以通过编辑服务端的.hg\hgrc来配置。

图12

当然，这样做是不安全的。然而如果你的工作环境是一个被保护的比较好的局域网，并且该局域网中的同事是值得信赖的，那么这样做也是可以的。否则的话，你需要去读一下有关安全的章节。

好了，现在重启服务。

图13

现在就可以推送了：

图14

现在，水银的世界看起来就是这样：

图15

我知道你在想什么，你在想，“很奇怪啊，为什么这些仓库中只有变更信息而没有文件？ guac文件在哪里？”

是的，很奇怪。然而分布式版本控制器就是这么工作的。仓库中只包含了变更栈。

我们可以使用网页浏览器来一瞥现在的中心仓库：

图16

现在我想要Rose来帮忙我的工作。Rose在测试组。

图17

Rose使用 hg clone命令来获得她自己的完整的仓库拷贝。 hg clone命令带两个参数。一个是仓库的源地址，一个是目标文件夹的名字。她现在构建了她自己的 recipes文件夹。

图18

利用 hg log命令，她看到了所有的历史。她实际上下载了整个仓库，包含了在这个仓库发生的所有历史。

Rose将要完成一个变更，并且提交到中心仓库：

图19

她现在进行提交。注意，即使服务器没有运行，提交的过程也能在她的机器上完成。

图20

当Rose在进行她的变更之时，我也可以在同时进行我的变更。

图21

当我提交的时候，你会发现我的变更集#2与Rose的变更集#2并不相同。

图22

我们的历史开始分离。

图23

不用担心……过一会儿我们就会看到如何将这些分离的变更合到一起。

Rose可以在离线状态继续她的工作。只要愿意，她可以作出任意多的变更，然后提交也可以，revert也可以。直到在某一时刻，她想要与外界分享她提交的内容。她可以输入hg outgoing来显示她可以上传到中心仓库的所有变更集。如果她再输入hg push，则这些变更集会全部上传到中心仓库中。

图24

可以这样来认识 hg outgoing：它就是简单地列出当前仓库有，而中心仓库没有的。

OK，Rose推送了她的变更。

图25

现在水银的世界变成了这样：

图26

当我从当天的第四个拿铁休息中回来，我也准备要推送我的变更了。

图27

啊……失败了！顺便要说的是，看到那条信息了吗？就是那条说要用 push -f to force的那条。那是一条很糟糕的建议。永远永远不要使用 push -f来强制推送。否则你会后悔的。请暂时相信我。

Rose能推送成功而我却失败了的原因是，我们两个人都做出了变更，而她先我一步推送了。现在需要先进行合并。而水银知道这一点。

我现在要做的是获取那些在中心仓库中有的，而我没有的。从而我可以合并它们。

图28

上面有一个+1heads。这个意思是我之前就一条主线，现在变成有两条线了，变成了有两个头的怪物。就像这样：

图29

现在在我的仓库里面有两个版本了……我有我的版本：

图30

还有Rose的版本：

图31

现在要我来合并它们。幸运的是，这很简单。

图32

看， hg merge命令将我的两个头合并到了一起。在当前的情况下，由于我们是分别编辑的文件的不同部分，因此根本没有任何冲突。

我还需要提交一下。这很重要。如果合并失败了，我也总能回滚并且再次尝试。由于合并很成功，我打算提交它。然后我就可以将我的变更推送到中心仓库了。

图33

现在中心仓库的内容就和我做的同步了：

图34

OK，现在我有了Rose的变更，以及我的变更，然而Rose却还没有我的变更。
Rose这时需要拉下仓库中的最新版本。

图35

然后你会感到有一点奇怪。因为即使Rose将新的变更都拉到了她的仓库中，它们竟然没有出现在她的工作目录中。

图36

然而在她的仓库中其实是有新的变更的……

图37

它们不再她的工作目录中是因为她仍然在变更集#2上工作。你可以通过“parent”命令来看到。

图38

水银总是对我们很友好。它保证我们拉的很安全；它所做的就是给我们其他人做的最新的变更。我们可以在自己方便的时候再转换过去。

记住，不带任何参数的hg up命令会将工作目录更新到最高的变更集。在此例中为数字4：

图39

当一个团队在工作时，你的工作流看起来大概是这样的：

1. 如果你一段时间没搞了，那么就先去获得最新的版本：
   • hg pull
   • hg up
2. 做一些变更
3. 提交它们（本地）
4. 重复步骤2-3直到你满意了并且想要与他人的工作合并
5. 当你准备好要分享时：
   • hg pull来获得别人的变更（如果有的话）
   • hg merge来将它们合并到你的里面
   • 测试！保证合并没有把什么事情变糟
   • hg push

自测

以下是你学完这篇教程后应该会做的：

1. 建立中心仓库并且让团队成员从此处拷贝。
2. 把变更推到中心仓库中。
3. 从中心仓库拉取变更。
4. 从不同的贡献者处合并变更。