一群开发人员如何通过 Mercurial 修复先前发布版本中的多个错误？

Question

好的，你们很好的人回答了我的问题问得很好，我很感激。

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

和以前一样，我们在单个存储库中使用 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 团队中的其他开发人员拉动并更新到这个新头，并将他们的贡献添加到错误修复中，根据需要提交和推送/拉动
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. 您合并具有 devel trunk 的版本

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

Answer 3

Git 方面有一个工作流程，称为 Git Flow。该工具本质上自动化了许多涉及的乏味工作（从生产稳定分支创建一个分支，提交，将分支合并到当前新工作所在的位置）。

有一个 Mercurial 扩展可以为您提供 Hg 的确切工作流程：Hg Flow。我已经使用过它（尽管不是用于大型应用程序）并且我真的很喜欢它 - 它像 Git Flow 一样自动执行所涉及的步骤，并将 Git 社区的智慧带到了 Hg-land。