mercurial - 帮助了解在Mercurial分支的好处

Question

我一直在努力理解分支的好处。我无法推送到带有2个头或2个分支的 repo ...所以我为什么需要/使用它们？

Answer 1

首先，您甚至可以推两个头，但是由于您可能不想这样做，因此默认行为是阻止您执行此操作。但是，您可以强制执行推送。

现在，关于分支，让我们在非分布式版本控制系统(例如Subversion)中采用一个简单的方案。

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

好的，现在您的同事已经进行了几个小时的更改工作，因此他做出了 promise 。这使中央存储库的修订版升至101版。您仍在本地使用100版，并且仍在进行更改。

在某个时候，您已经完成，并且想要提交，但是Subversion不允许您这样做。它说您必须先进行更新，然后才能开始更新过程。

更新过程希望接受您的更改，并假装您实际上是从修订版101而不是版本100开始的。如果您的更改与您的同事所做的操作没有冲突，那么一切都是花一现，但是如果您的更改有冲突，则您有一个问题。

现在，您必须将自己的更改与他的更改合并，事情可能会变得一团糟。例如，您可能最终合并了一个文件，然后合并了第二个文件，或者您认为是这样，然后合并了第三个文件，突然发现有些细节有误，那么最好合并合并第二个文件的方式有所不同。

除非您在更新之前对所做的更改进行了备份，否则迟早您会忘记的，那将是一个问题。

现在，以上情况实际上很普遍。好吧，也许不是合并部分，这取决于在同一区域或同一时间正在处理多少文件，但是Subversion的“提交前必须更新”部分非常普遍。

那么Mercurial是如何做到的呢？

好吧，Mercurial在本地提交，它根本不与任何远程存储库通信，因此它不会阻止您提交。

因此，让我们再次尝试上述情况，只是这次是在Mercurial中。

远程存储库中最重要的变更集是修订版100。你们俩都已将其克隆下来，并且你们都从修订版100开始着手进行更改。

您的同事在本地完成了更改并做出了 promise 。然后，他将自己的变更集推到中央存储库中，使那里的提示升至修订版101。

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

那么这有什么不同呢？

好吧，您的更改现在已经提交，没有办法，除非您真的努力避免意外丢失或销毁它们。

这是三个正在使用的存储库及其当前状态:

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 changeset(将他的更改和您的更改合并的M)继续。

上面的描述是由于Mercurials的分布式性质而发生的。

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

但是，其性质与上述描述相同。只要有不止一个人在Mercurial上进行项目工作，您就会得到分支机构，这是一件好事。