在我们最近关于分支策略的讨论中，有一个
相当好的讨论。
jgifford25的回答包含了Subversion开发人员称为“
敏捷发布策略”的链接，看起来与Plastic公司建议的类似-每个特性一个分支，将合并到发布分支而不是主干。我认为这不是一个好主意，也不认为这是一个好主意。我也不认为这是巧合，在两种情况下，这个想法都是由SCM开发人员推动的-我认为这些家伙有一个“万物皆钉子”的情况，并认为任何过程问题都可以通过更多、更大的SCM来解决。
所以为什么这个想法是错误的？让我们遵循Plastic团队的论点。他们将此过程建立在一个核心思想上：“保持主线干净”。到目前为止还不错。然后他们提出了一个类似于三段论的论证：
1. 如果你将有问题的代码提交到主干，构建就会失败。
2. 失败的构建是不好的。
3. 因此，不要将代码提交到主干。
这个问题在于它完全误解了为什么失败的构建是不好的。失败的构建本身并不是坏事（尽管它们没有帮助，因为它们会阻碍开发），它们之所以不好是因为它们意味着“有人已经提交了有问题的代码”。真正的问题在于有问题的代码，而不是失败的构建——有问题的代码才真正有可能造成损害（丢失用户数据、丢失空间探测器、全球热核战争等等）。
他们的解决方案是让人们在其他地方检查他们的错误代码，以便不会破坏构建。这显然根本没有解决错误代码的实际问题 - 相反，它是一种掩盖错误代码的方式。事实上，我不清楚何时检测到错误 - 是在任务分支最终确定并合并到发布分支时吗？那听起来就像是将困难工作推迟到发布周期的后期，这是一个非常糟糕的想法。
真正的解决方案是根本不要提交错误代码。为了实现这个目标，一个错误的构建实际上是好的，因为它告诉你有错误的代码，让你去修复它。事实上，这正是持续集成的整个重点 - 你早期和经常地合并到一个单一的主干，这是实际发布的原型，所以你尽可能早地检测到你打算发布的问题。这绝对需要“不稳定主干”模型或其同构。
这篇博客文章中
orangepips的回答提到了Ubuntu关于将过程作为推动这一想法的驱动力的想法。但看看Shuttleworth实际说了什么：
这是我在最后一点上的强调，但这是Shuttleworth的最终目标：他希望能够随时发布版本。一个将合并和测试推迟到发布过程中的过程（如Plastic模型）不可能做到这一点。
相反，如果你想看看能够做到这一点的过程是什么样子的，请看看精益团队的做法：一个代码线，持续集成（以小时甚至分钟为尺度，而不是以天或周为尺度），没有破损的代码。
因此，总结一下：不要这样做。只需一个代码行，并尽可能经常将工作代码检入其中。简单明了。
PS：好吧，你可能想创建发布分支来稳定和修复实际的发布版本。理想情况下，你不需要这样做，但你可能需要。
PPS：如果你有一个CI测试套件，在检入之前运行太慢（例如需要一个小时的功能测试），那么你可以使用任何DVCS来拥有两个存储库：一个脏存储库，开发人员合并到其中，以及一个干净存储库，由一个脚本推送，该脚本监视脏存储库的变化，构建和测试新版本，并在通过后推送到干净存储库。然后，你可以从干净存储库中进行按需发布（供QA等使用），而开发人员可以从干净存储库更新以保持当前状态。他们显然必须立即从脏存储库更新才能合并。
