关于将新功能引入稳定分支的业务流程，我们有以下要求 我们有一条稳定的生产线，可以交付给我们的客户。我们还有一个开发线，我们开发新功能。有时，我们决定需要将一些开发的功能引入稳定的释放线。不是全部，而是其中一些。如何组织分支机构（我们正在使用mercurial），以便我们可以选择我们想要应用于稳定分支的功能？ 另一方面，我们需要有一个分支，我们将所有功能集成到一个分支中，称之为dev分支（从稳定分支派生）。
其中一个想法是建立一个稳定的分支，dev分支（从稳定中一次派生）和每个特征的单独分支。
错误在稳定分支上得到解决，并且不时将更改提取到其他分支（开发和特征分支）。一旦做出将特定特征集成到稳定分支的决定，则仅将给定特征分支与稳定分支合并。此外，dev分支上不时会引入功能分支（用于集成正在开发的所有功能）。
答案 0 :(得分：0)
您的潜在解决方案可行，并且与GitFlow非常相似，可以轻松应用于mercurial。
Master将是您的稳定分支（可能是默认＆＃39;），并且您正在发布分支，这可能是一个好主意或坏主意，具体取决于您的开发/测试过程。无论哪种方式，标记版本都是一个好主意。
不是将您的功能分支定期合并到您的dev分支中，您可以将已完成的功能合并到dev中，然后将它们传播到其他活动功能分支。如果您的优先级发生变化（在完成集成测试后），这使您可以灵活地尽早发布已完成的功能。如果您定期将未完成的功能合并到开发分支中，如果突然确定需要尽快发布已完成的功能，则很难找到安全的发布点。如果您特别警惕与它们的集成问题并希望尽早发现它们，您仍然可以选择将功能分支直接合并到另一个功能分支中。
使用Gitflow中概述的修补程序/维护分支，可以让您保持“稳定”的神圣性。科。您可以为每个单独的修复分支，将其合并回来并在完成时关闭分支，或者保持一个持续的维护分支，这必须与Stable保持同步。我更喜欢每个修复程序的分支灵活性。
此外，对于短期分支，例如小功能或修补程序，您可以考虑使用Bookmarks，但这取决于您对更改历史记录的看法。