问题描述
|
好的，很好，人们很好地回答了我的问题，我很感激。
但是，现在我意识到这不是一个正确的问题，所以我有另一个问题（尽管我确实认为前面的问题将对其他人有用）。
和以前一样，我们在单个存储库中使用Mercurial。我们有一个master分支和一个development分支（以及Feature分支，但它们与当前问题无关）。
我们用发行版（5.1.0.102等）标记master分支。我们在发展上不断发展。
我真正想做的是将多个不同的修补程序与以前的版本捆绑在一起，以便创建一个包含修补程序集合的维护版本。
或者，像以前一样，这是我真正需要的：
以一组开发人员可以一起工作的方式更新到我们发布的版本（例如6.1.1）
该组开发人员修复了许多错误。
将结果代码状态标记为（6.1.2）
建立这个新的6.1.2代码库。
将这些修补程序迁移到开发分支
这样做的方式使我可以回到6.1.2并在需要的地方修复错误
或者，我需要基于以前的版本创建维护版本，其中包含来自各个开发人员的工作。
我怎样才能做到这一点？
解决方法
您先前提出的问题的公认答案仍然有效，并且在问题中概述问题的方式是……很好……正确的解决方法。
所以基本上我不明白你在问什么或为什么问。
这是您应该做的。
其中一位开发人员通过更新回上一个版本的焦点（即6.1.1版本的变更集）来开始工作。
然后，他进行一些与错误修正相关的更改，提交并推送回中央存储库。请注意，这将创建另一个头部。很好（如果不是，请参见下文）
Tiger团队中的其他开发人员会拉动并更新到这个新的头，然后将他们的贡献添加到错误修正中，并根据需要提交和推/拉
在某个时候，您拥有一个新版本，例如6.1.2，因此您为最终更改集创建了一个标签
然后，您更新到上一个头（开始完成整个工作之前的那个头）并合并到6.1.2头中，这会将所有这些错误修正带回到主分支中以用于将来的版本
它看起来像这样：
如果您忽略6.1.2中的所有错误修复，则R5将是合并提交，R4将是当前目录。
然后，如果您想回来修复更多内容以得到6.1.3版本，它将看起来像这样（您遵循与上述完全相同的计划）：
在这里，R9将是项目的下一个主要版本的当前负责人，R10将是合并提交，该合并提交将6.1.3中的错误修正带回了该将来的版本。
,您的步骤几乎是正确的。我的建议是这样的：
使用主干作为开发分支
当您需要发布时，可以创建一个新分支
在稳定之前，所有错误修复都在新分支上进行了1-2天
您启动
您将发布与开发主干合并
如果发现严重错误，请转到步骤1。
,在Git端有一个工作流程，称为Git Flow。该工具实质上可以自动执行很多繁琐的工作（在生产稳定的分支上创建分支，提交提交，合并分支到当前新工作所在的位置）。
有一个Mercurial扩展，可为您提供有关汞的确切工作流程：汞流量。我已经使用了它（尽管不是用于大型应用程序），而且我真的很喜欢它-像Git Flow一样自动执行涉及的步骤，并将Git社区的智慧带到Hg-land。