Question

我很难理解分支是如何有益的。我不能用2个头或2个分支推进回购...所以为什么我需要/使用它们？

Answer 1

首先，你可以用两个头来推，但由于你可能不想这样做，默认行为是阻止你这样做。但是，你可以强迫推动。

现在，至于分支，让我们在非分布式版本控制系统中采用一个简单的场景，比如Subversion。

假设您有一位与您在同一项目中工作的同事。 Subversion存储库中当前最新的变更集是修订版100，你们都在本地更新，以便现在你们两个都拥有相同的文件。

好的，现在你的同事已经在几个小时内完成了他的工作，所以他承诺了。这使得中央存储库达到了修订版101.您仍然在本地修订版本100，并且您仍在处理您的更改。

在某些时候，你完成了，你想提交，但Subversion不会让你。它说你必须先更新，所以你开始更新过程。

更新过程想要进行更改，并假装您实际上是从修订版101而不是100开始。如果您的更改与您的同事提交的任何内容没有冲突，则所有更改都是hunky dory，但如果您的更改冲突，你有问题。

现在你必须将你的变化与他的变化合并，事情可能会变得混乱。例如，你可能最终合并一个文件OK，第二个文件OK，或者你认为，然后第三个文件，你突然发现你有一些错误的细节，它会更好以不同方式合并第二个文件。

除非您在更新前备份了更改，否则迟早会忘记更改。

现在，上述情况实际上很常见。好吧，也许不是合并部分，它取决于有多少同时在同一区域或文件中工作，但“提交前必须更新”部分与Subversion相当普遍。

那么Mercurial是如何做到的？

嗯，Mercurial在本地提交，它根本不与任何远程存储库通信，所以它不会阻止你提交。

所以，让我们再次尝试上面的场景，这次是在Mercurial。

远程存储库中最顶端的变更集是修订版100.您已经克隆了它，并且您已经开始处理修订版本中的更改。

您的同事完成了他的更改并在当地承诺。然后他将他的变更集推送到中央存储库，将其提示到修订版101.

然后，您完成更改，并在本地提交，然后您想要推送，但是您收到了您已经发现的错误消息，并且正在询问。

那么这有什么不同？

嗯，您的更改现在已经提交，除非您非常努力意外丢失或销毁它们。

这是正在播放的3个存储库及其当前状态：

Colleague       ---98---99---100---A

Central         ---98---99---100---A

You             ---98---99---100---B

如果您要推送，并且被允许这样做（或强制推送），中央存储库将如下所示：

Central         ---98---99---100---A
                               \
                                +--B

两个脑袋。如果你的同事现在被拉了，他应该继续从哪个工作？这个问题是Mercurial默认会阻止你造成这种情况的原因。

所以请你拉，然后在你自己的存储库中获得上述状态。

换句话说，您可以选择影响您自己的存储库并在那里创建多个头，但您不会将此问题强加于其他任何人。

然后你合并，你必须在Subversion中进行相同类型的操作，除了你的变更集是安全的，它已被提交，你不会意外地破坏或破坏它。如果，在合并中期，你想重新开始，你可以，没有任何损失，没有伤害。

合并后，您的本地存储库如下所示：

You             ---98---99---100---A----M
                               \       /
                                +--B--+

这现在可以安全推送，如果你的同事现在拉，他知道他必须继续M变更集合，即合并他和你的变化的变更。

以上描述是由于Mercurials的分布式性质所致。

您还可以为分支命名，以使其更加永久。例如，您可能希望将分支命名为“stable”，以表示该分支上的任何变更集已经过全面测试，并且可以安全地发布给客户或投入生产。然后，只有在完成测试后才能将更改合并到该分支上。

然而，性质与以上描述相同。每当有多个人使用Mercurial处理项目时，你将获得分支，这是一件好事。

Answer 2

每当制作一个repo的一个克隆并在这些克隆中进行提交时，无论你是否使用hg branch命令命名它们，都会发生分支。我的理念是，你不妨给他们起个名字。它让事情变得更加混乱。