稳定分支的樱桃采摘新功能

Question

当涉及到向稳定分支引入新功能的商务过程时，我们有以下要求。
我们有一条稳定的生产线交付给我们的客户。我们还有一个开发线，开发新功能。有时候，我们认为我们需要将一些开发的功能引入稳定版本。并非全部，但其中一些。如何组织分支（我们使用的是mercurial），以便我们可以选择我们想要应用于稳定分支的功能？
另一方面，我们需要有一个分支，我们将所有功能集成到一个分支中，称之为dev分支（它来自稳定分支）。

其中一个想法是有一个稳定的分支，开发分支（这是从稳定一次派生）和每个功能的独立分支。
错误在稳定的分支上解决，并不时地将更改拉到其他分支（开发和功能的分支）。一旦做出将特定特征集成到稳定分支的决定，则只有给定特征分支与稳定分支合并。另外，功能分支有时也会在开发分支上提供（用于集成正在开发的所有功能）。

Answer 1

您的潜在解决方案将起作用，并且与GitFlow非常相似，可以很容易地将其应用于mercurial。

硕士将是你的稳定分支（大概是'默认'），并且你正在优先发布分支，根据你的开发/测试过程，这可能是一个好的或坏的想法。无论哪种方式，标签发布都是一个好主意。

您可以将您的功能分支定期合并到您的开发分支，而不是将完成的功能合并到开发中，然后将它们传播到您的其他活动功能分支。如果您的优先级发生变化（当然，完成您的集成测试后），这使您可以灵活地提前发布已完成的功能。如果您定期将不完整的功能合并到开发分支中，如果突然决定已经完成的功能需要尽快发布，您将难以找到安全的发布点。如果您对与他们的集成问题特别谨慎并且希望尽早地捕捉它们，您仍然可以选择将功能分支直接合并到另一个功能分支中。

使用Gitflow中概述的修补程序/维护分支将允许您维护'stable'分支的神圣性。您可以为每个单独的修补程序分支，将其合并回去并在完成时关闭分支，或者保留一个正在进行维护的分支，这必须与Stable保持同步。我更喜欢每个修补程序的分支灵活性。

另外，对于短期分支，例如小功能或修补程序，您可能会考虑使用Bookmarks，但这取决于您对更改历史记录的感受。