Question

Mercurial About页面说：

“传统版本控制系统比如Subversion是典型的客户端 - 服务器架构用于存储修订的中央服务器一个项目。相比之下，Mercurial 真正的分布，给每个人开发人员整个本地副本发展历史。这种方式有效独立于网络访问或中央服务器。承诺，分支合并快速而便宜。“

因此，当每个开发人员从 _ （？）获得克隆时，每个开发人员都可以开始为自己开发项目。 10个月后，每个人都做了一些事情，并以完全不同的方式改变了RootViewController。

现在，克隆整个事情有什么意义？当Dev A更改RootViewController时，Dev B希望根据该更改继续工作。或不？但Dev B将如何改变这种变化呢？通过每天克隆整个事情？他自己的变化怎么样？是否存在某种超级合并操作，将所有克隆合并为一个大的超级克隆，每个人都必须偶尔用他的个体克隆替换？

我确信Mercurial很酷且很有用。但我只是不明白。

Answer 1

我发现 basics 是对Mercurial的一个很好的介绍。

你必须从哪里开始。 hg init

所有开发者都应该有一些共同的基础/祖先。 hg clone

他们必须从其他开发者那里获得更改/发布他们自己的更改       hg push ， hg pull ， hg bundle

如果你拉了，你需要看看你自己的回购中有什么。 hg incoming

已做出哪些更改 hg diff

此外，有一个中央存储库很方便，每个人都可以推动他们的更改并从中获取更改。

Answer 2

通常，在像Mercurial这样的分布式版本控制系统中，您仍然可以拥有一个中央存储库。开发人员都要进入中央仓库，或者有一个人维护中央仓库，从个别开发人员那里获取补丁（例如，Linux使用这种方法）。

如果你不使用那种开发模式，那么通常你只需要在完成一个有趣的补丁时从其他开发者那里获取。

Answer 3

在分布式版本控制系统（DVCS）中（mercurial和git）没有人是主人。（即使是“服务器”也是一个任意选择的主人，对其他人的工作没有更多的权利）

每个开发人员都可以完成他的混乱而不会让其他人无法工作。你还记得上次有人犯了什么坏事，没有人可以工作吗？这在DVCS中是不可能的。

在Subversion / CVS中你应该进行分支以避免这些问题，但是合并很复杂，所以很少/不能完成每个任务。

在DVCS中，它不可能不分支，但合并很容易，应该在所有代码完成后完成（bug关闭，完成功能......）。您的开发人员可以拥有与任务打开一样多的分支。

Answer 4

取自a different question的回答：

关于DVCS，要记住的一点是，它实际上并不是关于它的分布式问题，而是关于分支和合并。 DVCS使分支和合并变得更加容易，以至于每个开发人员/设计人员/前端人员基本上都有自己的私有分支 - 他们的本地仓库。这样，他们可以并行工作，而不会踩到对方的脚趾。这意味着他们可以每隔几个小时检查一次代码而不是等待几天，直到他们完成所有操作来检查它。

如果你在任何类型的组织（公司，项目团队等），你仍然需要一个中央存储库，所以你有一个规范版本的代码。很少有团队在没有中央服务器的情况下使用完全分布式工作流，因为当您增加团队中的人数时，您的连接将增加到N ²，而它与中央服务器保持N.

Answer 5

如果每个开发人员克隆整个项目，然后只在本地提交，那么是的，你会遇到问题。我会说软盘源控制模型在那时可能略好一些，因为你没有在混合中引入另一个工具。

问题是，那不是你应该做的。

基本上工作流程就是这样。

每个开发人员都克隆本地存储库，并开始破解代码。

在某些时候，其中一个开发人员做了一些他想与其他人共享的提交，以便开发人员将他/她的更改推回到中央存储库。现在中央存储库有开发人员的更改，但其他开发人员都没有（但是。）

在他们自己的闲暇时间（但不是很少，或者你会遇到合并问题，就像你在问题中指出的那样），然后他们可以将这些更改下载到他们自己的存储库中。

当他们这样做时，他们之后在他们的存储库中有分支。

首先，当他们全部克隆时，他们拥有中央存储库中存在的最新变更集，然后他们有两个分支，一个沿着线性路径（通常）进行自己的更改，另一个带有他们下拉的所有更改来自存储库。

即。他们最终得到这样的东西，（C）是每个人克隆的常见变化：

   o---o---o---o  <-- changes from central repository
  /
(C)
  \
   o---o---o---o  <-- their changes

所以，现在他们可以选择了。他们可以继续在他们自己的分支上工作，他们可以切换到继续在他们刚从中央存储库获得的分支上工作，或者他们可以合并两者并获得两个世界中最好的。通常他们会选择选项3，合并。

导致这一点：

   o---o---o---o
  /             \
(C)             (M)---o---o---o  <-- continued working after the merge
  \             /
   o---o---o---o

如果他们现在将他们的更改推回到中央存储库，他们自己的分支，合并变更集以及他们在合并后提交的任何内容，然后被推回到中央存储库以供其他人使用。

通过这种方式你可以看到：

当您准备好它时，您可以推拉，这意味着您可以孤立地工作，直到您准备好与他人分享您的更改或接受其他人的更改
您定期将自己的更改与其他人合并

Answer 6

其他人的回答是对的，但我想专门回答你的问题

现在，克隆整个事情有什么意义？

您现在拥有自己的私人存储库。这使得大量操作更快，因为它们是本地的，但也允许您进行私密更改，直到您想要共享它们。

这样做的结果是开发人员可以将“签到”与发布他们的作品分开。这意味着当没有签入任何内容时，您不会获得大量时间，因为“它还没有准备好上市”。

当Dev A更改RootViewController时，Dev B希望根据该更改继续工作。或不？但是Dev B将如何改变这种变化？

当Dev A很乐意分享他的变化时，他可以：

'推'他改变他们都克隆的原始回购。然后Dev B可以从原始仓库“拉”出来。
'服务'他的回购，所以Dev B可以直接“拉”他。
将他的更改“捆绑”到一个文件中，然后发送给Dev B.然后他可以将它们“拆分”到他的回购中。
......可能是其他一些我忘记过的方法。

每天克隆整件事？

克隆仅用于创建存储库的新副本。想想“svn co”。

您通常会将变更集“拉”到回购协议中，有点像'svn update'

他自己的变化怎么样？是否存在某种超级合并操作，将所有克隆合并为一个大的超级克隆，每个人都必须偶尔用他的个体克隆替换？

当变更集进入仓库时（例如通过'拉'），它们将存在于另一个分支上。据说存储库有多个“头”，这是分支的开放端。通过合并这些头，他将得到一个包含两个分支的变化的单一版本。然后Dev B可以继续工作。你会得到一个看起来像这样的图表。

合并前：

     /----o----o Head 'Dev A'
----O Central    
     \----o----o Head 'Dev B'

合并后：

     /----o----o---
----O Central      \
     \----o----o----o Head 'Dev B'

这种合并可能听起来像是一项额外的工作，但是因为Mercurial使用了有关开发人员何时拆分的信息，并且不仅仅是“区分”这两个头，所以它非常聪明。一般来说，合并冲突很少见。

也许Dev A做了更多的工作，然后发布到中央回购（注意：之前Dev B直接从他那里获得了Dev A的更改。也许B正在开发一个依赖于A代码的功能，需要测试版早期的代码）。您最终可能会得到如下图表：

Dev A /----o----o----o----o----o----o----o--\
     /            \              \           \
----O Central      \              \           o--\        /-o
     \              \              \              \      /
Dev B \----o----o----o----o----o----o----o----o----o----o

Dev B在开发过程中拍摄了Dev A代码的几个快照，当Dev A将他的最终代码发布到中央存储库时，Dev B能够提取额外的更改，与它们合并，并推动他的所有也改回中央回购。因为mercurial知道B对A代码的快照，所以当它从中央仓库撤出时并没有感到困惑。它只是说“哦，我已经有了一些。”

所以，对我来说DVCS的两个杀手锏是：

签入不再意味着发布。
开发人员可以以受控方式共享代码，而无需通过中央仓库进行发布。

哇，这很长，但希望它有所帮助。

Mercurial - 分发克隆的重点是什么？

6 个答案: