更新:我们最终使用了一个非常类似于 this schema 的过程(感谢 neuro 的链接)。我们将存储库修改为默认稳定的状态(并且与我们的生产环境具有相同的代码)，我们有一个开发分支，用于新内容的功能分支，并使用发布分支进行发布。一切似乎都很完美。
背景故事
我们的团队最近从使用 SVN(使用 ToroiseSVN Windows 客户端)切换到 Mercurial(使用 TortoiseHg Windows 客户端)进行版本控制。我们已成功导出 SVN 存储库并将其导入 Mercurial 存储库。
我们现在有一个 Mercurial 存储库，我们可以在其中查看整个修订历史(Mercurial 中的变更集)。
过去我们是怎么做到的
过去的生活很简单；我们的开发过程并不像现在这样真正的多流。 trunk 用于保存所有代码 - 甚至是仍在进行中的更改(只要它没有破坏 trunk)。在使用 SVN 管理发布时，我们会检查主干(其中包含所有代码)，还原我们不希望作为发布一部分的个别更改，并创建一个标签 为之。
使用 SVN 挑选我们想要的代码很容易。修复以前版本的错误并确保它是主干的一部分也很简单。
我们现在在做什么
在 Mercurial 中，我们需要能够获得“主干”(Mercurial 中的默认)的快照，其中包含恢复的个别更改。我们可以使用 hg revert 来做到这一点。
为了对此进行快照，我们创建了一个“命名分支”——我们暂时称它为 Build-4.0.1。
挑战出现的地方
当在 Build-4.0.1 中发现错误时，开发将照常在默认 上继续。让我们假设错误存在于其中一个还原的文件中。我们从 Build-4.0.1 的分支更改代码，创建一个新的“命名分支”(Build-4.0.2)并希望 merge 它回到 default 而不是将恢复的代码推到较新代码的顶部。我们怎样才能做到这一点？
或者，在 Mercurial 中是否有更好的工作流程来管理发布和我们的代码？我很喜欢这个 wonderful SO answer on managing release branches 的外观，尽管我不确定我们如何从现在的状态过渡到它(默认 中的飞行中的东西)。
注意:我查看了 Transplant extension ，但尚未使用它 - 它能否成为应对这一挑战的解决方案的一部分？
最佳答案
嗯，首先，你对 revert 的使用对我来说似乎很奇怪。通常它用于将对工作副本所做的修改恢复到存储库的版本。
将工作副本倒退到某个点的通常方法是更新:
hg update -r 1234
从那里，您可以标记、修改、提交等。
要 merge 回去，您只需将您的发布分支 merge 到默认分支。它会像一个魅力一样工作，除非它是不同的/旧的版本。
移植工作正常，但做一些与 merge 有点不同的事情:它将您的变更集作为“差异”并将其作为新修改应用。
要管理您的发布，您可以查看另一个答案(由我提供):
How to use mercurial for release management?
我们使用的是拥有最稳定版本的克隆/主分支，该版本在某些时候发布。在这个 clone : 分支上，我们可以修复关键错误(hotfix)。同时，我们使用开发克隆/分支进行开发。一旦从稳定版到开发版完成，修补程序就会 merge 。当前开发完成后，我们将开发 merge 到稳定/默认。
这schema很好理解事物:)
祝你好运!
关于version-control - 在 Mercurial : how to revert individual files, "tag"中管理代码并能够维护它，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8355225/