Mercurial - 分发克隆有什么意义？

Question

Mercurial 关于页面显示：

“传统版本控制系统 比如 Subversion 就是典型的 客户端-服务器架构 中央服务器存储修订版本 一个项目的。相比之下，水银 是真正分布式的，给每个 开发者整个本地副本 发展历史。这样就可以了 独立于网络访问或 中央服务器。提交、分支 并且合并既快又便宜。”

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

现在，当 Dev A 更改 RootViewController 时，Dev B 想要继续基于该更改的工作有什么意义？ B 每天都克隆整个东西吗？是否有某种超级合并操作可以将所有克隆合并成一个大的超级克隆，每个人都必须偶尔用他自己的克隆来替换它？ ？

我确信 Mercurial 很酷而且很有用，但我就是不明白。

Answer 1

我发现这里的基础知识很好地介绍了 Mercurial。

你必须从某个地方开始。 hg初始化

所有开发人员都应该有一些共同的基础/祖先。 hg克隆

他们必须从其他开发人员那里获取更改/发布自己的更改
hg 推送、hg 拉动、hg 捆绑

如果你拉取了，你需要看看你自己的仓库里有什么。 HG 传入

进行了哪些更改hg diff

此外，拥有一些中央存储库很方便，每个人都可以在其中推送更改并从中提取更改。

Answer 2

一般来说，在像 Mercurial 这样的分布式版本控制系统中，您仍然拥有一个中央存储库。要么开发人员推送到中央存储库，要么由一个人维护中央存储库，从各个开发人员那里获取补丁（例如，Linux 使用这种方法）。

如果您不使用该开发模型，那么是的，通常您只需在其他开发人员完成有趣的补丁后就可以从他们那里获取。

Answer 3

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

每个开发人员都可以在不让其他人的工作变得无法使用的情况下搞砸自己的事情。你还记得上次有人做了坏事而没有人能工作吗？这在 DVCS 中是不可能的。

在 Subversion/CVS 中，您应该进行分支以避免这些问题，但合并很复杂，因此很少/不是每个任务都执行合并。

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

Answer 4

取自我对另一个问题的回答：

关于 DVCS 需要记住的一件事是，它实际上与分布式无关，而是与分支和合并有关。 DVCS 使分支和合并变得更加容易，以至于每个开发人员/设计人员/前端人员基本上都有自己的私有分支 - 他们的本地存储库。这样，他们就可以并行工作，而不会互相干扰。这意味着他们可以每隔几个小时检查一次代码，而不是等待数天直到完成所有工作才能检查代码。

如果您在任何类型的组织（公司、项目团队等）中，您仍然需要一个中央存储库，因此您拥有代码的规范版本。很少有团队使用没有中央服务器的完全分布式工作流程，因为随着团队人数的增加，您的连接数会增加到 N²，而使用中央服务器时连接数仍保持为 N。

Answer 5

如果每个开发人员都克隆整个项目，然后仅在本地提交，那么是的，您将会遇到问题。我想说软盘源代码控制模型在这一点上可能稍微好一些，因为您没有在组合中引入其他工具。

问题是，这并不是您应该做的全部事情。

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

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

在某些时候，其中一位开发人员已经完成了一些他想要与其他人共享的提交，以便开发人员将他/她的更改推送回中央存储库。现在，中央存储库具有该开发人员的更改，但其他开发人员都没有（还没有）。

在他们自己的闲暇时间（但不是太少，否则您将遇到合并问题，就像您在问题中指出的那样），他们然后可以将这些更改拉入他们自己的存储库中。

当他们这样做时，他们的存储库中就会有分支。

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

IE。他们最终得到这样的结果，(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

如果他们现在将更改推送回中央存储库，那么他们自己的分支、合并变更集以及他们在合并后提交的任何内容都会被推送回中央存储库以供其他人拉取。

通过这种方式，您可以看到：

1. 当您准备好时，您可以推送和拉取，这意味着您可以单独工作，直到您准备好与其他人共享您的更改或接受其他人的更改
2. 您将自己的更改与其他人定期

Answer 6

其他人的答案都对，但我想具体回答你的问题

现在，克隆整个东西有什么意义呢？

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

这样做的连锁反应是开发人员可以将“签入”与发布他们的作品分开。这意味着您不会有很长一段时间什么都没有签入，因为“它还没有准备好公开”。

当开发人员 A 更改 RootViewController 时，开发人员 B 希望根据该更改继续工作。或不？但开发 B 如何获得这种改变呢？

当开发人员 A 乐意分享他的更改时，他可以：

• 将他的更改“推送”到他们都克隆的原始存储库。然后，开发人员 B 可以从原始存储库中“拉”它们。
• “服务”他的仓库，这样 Dev B 就可以直接从他那里“拉取”。
• 将他的更改“捆绑”到一个文件中，该文件可以发送给 Dev B。然后他可以将它们“解绑”到他的存储库中。
• ...可能还有一些我忘记的其他方法。

每天都克隆整个东西？

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

您通常将更改集“拉”到存储库中，有点像“svn update”

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

当变更集被引入存储库（例如通过“拉取”）时，它们将存在于另一个分支上。据说存储库有多个“头”，它们是分支的开放端。通过合并这些头，他将获得一个包含两个分支的更改的单一版本。然后，开发人员 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 代码的功能，并且需要代码的 beta 版本早期的）。您最终可能会得到这样的图表：

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

开发人员 B 在开发过程中拍摄了开发人员 A 的代码的几个快照，当开发人员 A 将其最终代码发布到中央存储库时，开发人员 B 能够提取额外的更改，并与他们，并将他的所有更改也推回到中央存储库。因为 Mercurial 知道 B 拥有 A 代码的快照，所以当它从中央存储库中提取时，它不会感到困惑。它只是说“哦，我已经得到了一些。”

因此，对我来说，DVCS 的两个杀手级功能是：

• 签入不再意味着发布。
• 开发人员可以以受控的方式共享代码，而无需通过中央存储库并因此发布。

哇，虽然很长，但希望对您有所帮助。