我们采用了Vincent Driessen提出的分支模型，并且几乎按照他在文章中所描述的那样做所有事情。
只有在处理发布分支时，我们才会有所偏差。
Vincent 建议在从开发人员分支出来的分支中开发功能。当决定哪些功能进入下一个版本时，它们将被合并回开发人员并从中创建一个发布分支。
之后，特性分支应该只用于测试和错误修复。当发布被部署到 live 时，发布分支被合并回开发者和 master。
我们所做的是将功能直接合并到发布分支中：
我觉得这不是应该这样做的方式，我正在尝试考虑这实际上会使事情变得更加复杂的情况。
我能想到的一个是：
假设一个新的Feature c正在构建Feature a，它已经合并到一个发布分支中。我必须首先将发布分支合并回开发人员，以便能够从开发人员创建一个新的Feature c分支。
在其他情况下，这种分支模型会使事情变得更复杂吗？
我能想到的一种情况是，这会使事情变得复杂，它会开始阻碍进一步的发展。
假设您正在开发一个功能 A，它将在您的下一个版本中立即使用。现在有另一个开发团队将致力于特性 B，它严重依赖于特性 A，但它需要在几个 sprint 之后才能发布。因此，显然我们将从特征 A 中分支出特征 B。
现在，您在功能 A 中发现了一个错误，您的功能 A 即将发布，您有两种选择：热修复/破解或适当的代码重构和修复。
由于时间的限制，进行热修复是明智的，但考虑到未来我们需要适当的重构和修复。
好消息是我们可以两者兼得。
使用您的策略（据我了解），您的发布分支将收到所有补丁和热修复（包含 5 次以上的提交），因为您不能向功能 A 提交任何类似的内容（如果您严格遵守政策）。如果您一次拥有 10 多个功能，请考虑此类修复版本的数量。
但是根据 Vincent Driessen 的策略，在您的功能和发布之间始终存在开发分支，因此对于此类热修复，您可以合并回开发分支，然后从那里分支出热修复，然后合并回开发，然后再合并到发布。而且您的优势在于您的功能分支中的任何地方都没有黑客/热修复。基于该特征的其他特征可以继续并行。您可以放弃修补程序分支或从历史记录中删除。这只是一个观点，在这种情况下，您可能可以捍卫自己的策略。我愿意在我的回答中进一步讨论和更正:)
这是一个非常讨厌的图像，描绘了我正在传达的内容。
