一组开发人员如何通过Mercurial修复先前发行版中的多个错误?

| 好的,很好,人们很好地回答了我的问题,我很感激。 但是,现在我意识到这不是一个正确的问题,所以我有另一个问题(尽管我确实认为前面的问题将对其他人有用)。 和以前一样,我们在单个存储库中使用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。     

要回复问题请先登录注册