为什么将功能分支合并到发布分支中是一个坏主意？

Question

我们采用了Vincent Driessen提出的分支模型，我们几乎完成了他在article中所描述的一切。

只有在处理发布分支时，我们才会稍微偏离。

Vincent建议在开发人员分支的分支中开发功能。 当决定哪些功能进入下一个版本时，它们将合并回开发人员，并从中创建发布分支。

之后，功能分支应仅用于测试和错误修正。 当发布部署为live时，发布分支将合并回开发人员和主服务器。

我们所做的是将功能直接合并到发布分支中：

我觉得这不是它应该做的方式，而是我想要考虑这可能会让事情变得更复杂的情况。

我能想到的是：

假设一个新的功能c 正在功能上构建，该功能已经合并到发布分支中。我必须首先将发布分支合并回开发人员，才能从开发人员创建新的 Feature c 分支。

在其他情况下，这种分支模型会使事情变得更复杂吗？

Answer 1

我能想到的一个案例是，它会让事情变得复杂，它会阻止进一步的发展。

考虑一下你正在开发一个功能A，它将在你的下一个版本中立即发布。 现在还有另一个开发团队正在开发功能B，它很大程度上依赖于功能A，但它只需要在几次冲刺后才能发布。 所以，显然我们将从功能A中分出功能B.

现在，您发现功能A中存在错误，功能A的发布速度快，您有两种选择：热修复/黑客或正确的代码重新设置和修复。

随着时间的限制，明智地进行热修复，但考虑到未来我们需要适当的重新考虑和修复。

幸福的消息是，我们可以为两者而努力。

根据您的策略（根据我的理解）您的发布分支，将收到所有补丁和热修复（包含5个以上的提交），因为您无法提交任何类似的功能A（如果您对策略严格）。 如果您一次拥有10多个功能，请考虑发布此类修补程序的数量。

但是有了Vincent Driessen的策略，总有一个开发分支作为你的功能和发布之间的存储，所以对于这样的热修复，你可以合并回开发分支，然后从那里分支出来进行热修复，然后合并回开发然后发布。 而且您可以在功能分支中的任何位置都没有黑客/热修复功能。基于该功能的其他功能可以继续并行。 并且您可以放弃修补程序分支或从历史记录中删除。 这只是一个观点，在这种情况下你可能会捍卫你的策略。在我的回答中，我愿意进一步讨论和纠正：）

这是一幅非常讨厌的图像，描绘了我正在传达的东西。