一组开发人员如何通过mercurial修复以前版本中的多个错误？

Question

好的，you fine people answered my question quite nicely，我很感激。

然而，现在我意识到这不是一个正确的问题，所以我有另一个问题（尽管我认为前一个问题对其他人有用）。

和以前一样，我们在一个存储库中使用mercurial。我们有一个主分支和一个开发分支（以及功能分支，但它们与手头的问题没有密切关系）。

我们用版本（5.1.0.102等）标记主分支。我们在发展方面做我们的发展。

我真正想要做的是将许多不同的修复程序从先前版本中捆绑在一起，以便创建一个维护版本，这是一组修复程序。

或者，像以前一样，这是我真正需要的：

1. 以一组开发人员可以一起工作的方式更新到我们发布的地址（例如6.1.1）
2. 这组开发人员修复了一堆错误。
3. 将生成的代码状态标记为（6.1.2）
4. 构建这个新的6.1.2代码库。
5. 将这些修补程序迁移到开发分支
6. 以这种方式执行此操作，以便我可以返回6.1.2并在需要时修复错误

或者，我需要根据以前的版本创建维护版本，其中包括各种开发人员的工作。

我该怎么做？

Answer 1

您之前提出的问题的接受答案仍然存在，您在问题中概述的方式是......嗯......正确的方法。

所以基本上我不明白你要问什么或为什么。

这是你应该做的。

1. 其中一位开发人员通过更新回到上一版本的焦点（即6.1.1版本的变更集）来启动工作。
2. 然后，他进行了一些与错误修正，提交和推送回中央存储库相关的更改。请注意，这将创建另一个头。这很好（如果不是这样的话，见下文）
3. 他的Tiger Team上的其他开发人员，并更新到这个新头，并根据需要添加他们对错误修正，提交和推/拉的贡献
4. 在某些时候，您有一个新版本，例如6.1.2，因此您为最终变更集创建了一个标记
5. 然后你更新到上一个头（你开始这整个工作之前的那个）并合并到6.1.2头，这将所有那些错误修正带回到主分支以备将来的版本

看起来像这样：



这里的R5将是合并提交，如果你忽略6.1.2中的所有错误修正，R4将是当前的头。

然后，如果你想再回来修改6.1.3版本，它会看起来像这样（你遵循与上面完全相同的计划）：



这里R9将成为项目下一个主要版本的当前负责人，而R10将是合并提交，它将进入6.1.3的错误修正带回到未来的版本中。

Answer 2

你的步骤几乎是正确的。我的建议是：

1. 使用主干作为开发分支
2. 当您需要发布时，您需要创建一个新分支
3. 所有错误修复都在新分支上完成，持续1-2天才能稳定
4. 您启动

5. 您将版本与开发中心合并

6. 如果发现严重错误，请转到第1步。

Answer 3

Git方面有一个工作流程，名为Git Flow。这个工具实际上自动化了很多相关的乏味（从你的生产稳定分支创建一个分支，提交提交，将分支合并到你当前新工作的地方）。

Mercurial扩展程序为您提供了Hg：Hg Flow的确切工作流程。我已经习惯了它（虽然不适用于大型应用程序）而且我非常喜欢它 - 它像Git Flow一样自动执行所调用的步骤，并将Git社区的智慧带到Hg-land。