美文网首页开发@IT·互联网首页投稿(暂停使用,暂停投稿)
分布式版本控制软件水银(Mercurial)使用指南2

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

作者: 行之与亦安 | 来源:发表于2016-09-07 16:34 被阅读204次

    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. 从不同的贡献者处合并变更。

    相关文章

      网友评论

      本文标题:分布式版本控制软件水银(Mercurial)使用指南2

      本文链接:https://www.haomeiwen.com/subject/dkijettx.html