mercurial - Mercurial 如何与许多开发人员合作？

Question

我查看了一些已知产品的 Mercurial 存储库，例如 TortoiseHg和 Python ，尽管我可以看到多个人提交更改，但时间线总是看起来很干净，只有一个分支在前进。

但是，假设您有 14 个人在开发同一产品，这不会很快陷入在任何给定时间都有 14 个并行分支的分支噩梦吗？

例如，只有两个人，产品在变更集 X，现在两个开发人员都在周一早上开始开发不同的功能，所以他们都从同一个父变更集开始。

当他们提交时，我们现在有两个分支，然后有 14 个人，我们很快就会有 10+(可能不是 14...)需要 merge 回默认分支。

或者......我在这里没有看到什么？也许这不是一个真正的问题？

编辑 : 我看到我在这里真正要问的问题有些困惑，所以让我澄清一下。

我非常清楚 Mercurial 可以轻松处理多个分支和 merge ，并且正如一个答案所述，即使人们处理相同的文件，他们也不经常在同一行上工作，即使那样，冲突也很容易处理。我也知道，如果两个人最终创建了一个 merge hell ，因为他们在同一个文件中更改了很多相同的代码，那么这里就会出现一些整体规划失败，因为我们已经将两个功能放在完全相同的位置给两个开发人员，而不是试图让他们一起工作，或者一开始就将两者都交给一个开发人员。

所以不是这样。

我很好奇的是这些开源项目是如何管理如此干净的历史的。对我来说(正如一条评论所怀疑的那样)历史是否干净并不重要，我的意思是，我们确实并行工作，存储库能够反射(reflect)这一点，更好(在我看来)，但是这些存储库我'看过没有那个。他们似乎在按照 Subversion 模型工作，在这种模型中，您在更新和 merge 之前无法提交，在这种情况下，历史只是一条直线。

那么他们是怎么做到的呢？

他们是否“重新定位”这些更改，以便它们似乎遵循分支的最新提示，即使它们最初在分支历史中被提交了一点？移植变更集以使它们看起来'已经在主分支中提交？

还是我看过的项目在添加新事物方面太慢了(目前，我并没有回顾历史)，实际上他们一次只为一个人工作？

还是他们将更改推送给一位审查然后集成的中央维护人员？看起来不是这样，因为我查看的许多项目在变更集上都有不同的名称。

Answer 1

Or... What am I not seeing here? Perhaps it's not really a problem?

这不是一个真正的问题。在大型项目中，即使人们使用相同的功能，他们通常也不会使用相同的文件。当他们处理同一个文件时，他们通常不会修改相同的行。当他们修改相同的行时，应该手动进行 merge (对于受影响的行)。

这意味着实际上 80% 以上的 merge 可以由 Mercurial 本身自动完成。

举个例子:

你有:

[branch 1]  [branch2]
        \    /
         \  /
        [base]

编辑 :为清楚起见，分公司我在这里指的是未命名的分支。

如果您在 branch 1 中更改了文件但是 branch 2 中的同一个文件与 base 中的相同, 然后是 branch 1 中的版本被选中。如果文件在 branch 1 中都被修改和 branch 2使用相同的算法逐行 merge 文件: if line 1 in file1 in branch 1与 base 中 file1 中的第 1 行不同但是 branch 2和 base让第 1 行相等，branch 1 中的第 1 行被选中(等等)。

对于在两个分支中修改的行，Mercurial 会中断自动 merge 过程并提示用户选择要使用的行，或手动编辑这些行。

由于决定使用哪些行最好由修改这些行的人来完成，一个好的做法是让实现某个功能的人执行 merge 。这意味着如果我和你在同一个项目上工作，我实现我的功能，然后从中央/公共(public)存储库中提取(获取每个人都使用的最新版本)，然后将我的新版本与拉取的更改 merge ，然后发布它到公共(public)存储库(此时，公共(public)存储库有一个主分支，其中包含我 merge 的更改)。然后，您从服务器中提取它并对您的更改执行相同的操作。

这意味着每个人都可以在他们的本地存储库中做任何他们想做的事情，并且公共(public)/官方存储库有一个分支。这也意味着您需要确定人们应该 merge 他们的更改的时间范围。

我曾经在我的机器上拥有三个或四个存储库，这些存储库已经在不同的产品版本(存储库的不同分支)上编译，而我的主存储库中有几个不同的分支(一个用于重构，一个用于开发等等)。每当我将一个分支带入稳定状态(比如完成重构)时，我都会从服务器中拉取，将该分支 merge 到拉取的更改中，然后将其推回服务器并让任何人知道他们是否对受影响的文件，他们应该首先从服务器中提取。

我们过去每周一早上同步实现的功能，我们花了大约一个小时来 merge 所有内容，然后每周在服务器上构建一个给 QA(在糟糕的日子里，团队中的两个成员需要两个小时左右，然后每个人都会在他们的机器上提取一周的更改并将它们用作一周的新基础)。这是一个由八名开发人员组成的团队。