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

Question

我们采用了Vincent Driessen提出的分支模型,我们几乎按照他在文章中描述的那样做了所有事情.

只有在处理发布分支时,我们才会略有偏差.

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

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

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

我觉得这不是它应该做的方式,我试图想到这可能会使事情变得更复杂的情况.

我能想到的是以下几点:

假设一个新的Feature c正在建立在Feature a上,它已经被合并到一个发布分支中.我必须首先将发布分支合并回开发人员,以便能够从开发人员创建新的Feature c分支.

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

Answer 1

我能想到的一个案例是,它可以使事情变得复杂,它将开始阻止进一步的发展.

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

现在,您发现功能A中存在错误,功能A的发布快速接近,您有两个选项:热修复/黑客或正确的代码重新设置和修复.

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

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

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

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

这是一个非常讨厌的图像,描绘了我正在传达的东西.