我正在考虑从 HG 切换到 Plastic SCM（http://www.plasticscm.com，主要是因为它似乎提供了更好的 VS 集成），并且他们提倡“任务驱动分支”，即从主线分支每个特征。这是有道理的，但是，我有几个问题：
让我知道你们的想法！
谢谢。
在我们最近对分支策略进行的一次相当不错的讨论中， jgifford25 的回答包含一个链接，指向 Subversion 的一位开发人员所说的“敏捷发布策略”，这看起来与 Plastic 家伙的建议非常相似 - 每个功能一个分支，合并到发布分支而不是主干。我不认为这是一个好主意，我不认为这是一个好主意。我也不认为这是一个巧合，在这两种情况下，这个想法都是由 SCM 开发人员推动的——我认为这些人有一个“一切看起来都像钉子”的案例，并且认为任何流程问题都可以通过更多来解决和更大的单片机。
那么为什么这个想法不好呢？让我们跟随塑料家伙的论点。他们围绕一个中心思想构建这一过程：“保持主线原始”。到现在为止还挺好。然后他们提出了一个三段论，如下所示：
问题在于它完全误解了为什么损坏的构建不好。损坏的构建本身并不坏（尽管它们没有帮助，因为它们阻碍了开发），它们很糟糕，因为它们意味着有人签入了损坏的代码。真正的问题是损坏的代码，而不是损坏的构建 - 实际上有可能造成损坏的是损坏的代码（丢失的用户数据，丢失的太空探测器，全球热核战争，诸如此类）。
因此，他们的解决方案相当于让人们在其他地方检查他们损坏的代码，这样它就不会破坏构建。很明显，这对于处理损坏代码的实际问题根本没有任何作用——恰恰相反，它是一种隐藏损坏代码的方法。事实上，我不清楚在什么时候检测到损坏 - 当任务分支完成并合并到发布分支时？这听起来像是将困难的工作推迟到发布周期后期的好方法，这是一个非常糟糕的主意。
相反，真正的解决方案是根本不检查损坏的代码。在追求这个目标的过程中，一个损坏的构建实际上是好的，因为它告诉你有损坏的代码，它可以让你修复它。事实上，这就是持续集成理念的全部转折点——您尽早并经常合并到一个主干中，该主干是实际发布的原型，因此您可以尽早发现您打算发布的内容的问题可能的。这绝对需要“不稳定的主干”模型，或者与其同构的东西。
orangepips 的答案链接到的博客文章提到了 Ubuntu 关于进程作为这个想法的驱动程序的想法。但看看沙特尔沃思实际上是怎么说的：
这是我对最后一点的强调，但这是沙特尔沃思的最终目标：他希望能够随时削减发行量。像塑料模型那样，将合并和测试推迟到发布过程的过程不可能做到这一点。
相反，如果你想看看一个可以完成它的流程是什么样的，看看精益人员做了什么：一个代码线，持续集成（在几小时甚至几分钟的范围内，而不是几天或几周），没有损坏的代码.
所以，总而言之：不要这样做。拥有一个代码行，并尽可能多地将工作代码签入其中。简单的。
PS 好的，所以你可能想要发布分支来稳定和修复实际版本。理想情况下，您不会，但您可能需要这样做。
PPS 如果您有一个 CI 测试套件在签入之前运行速度太慢（例如功能测试需要一个小时），那么您可以对任何 DVCS 做的事情是拥有两个存储库：一个脏的，开发人员合并到的，和一个干净的，由一个脚本推送到脏存储库中，该脚本监视脏存储库的更改，构建和测试进入其中的新版本，如果它们通过，则推送到干净的存储库。然后，您可以从干净的存储库运行按需发布（用于 QA 等），并且开发人员可以从干净的存储库更新以在开发时保持最新状态。不过，他们显然必须在合并之前立即从脏存储库进行更新。
在阅读 PR之后，听起来他们似乎提倡在代码合并到主干/主/基线之前对其进行测试的模型（参见规则 #4）。这以一套单元测试为前提，并且这些测试涵盖了所做的任何更改。对于我参与的大多数项目，该套件不存在，而且可能永远不会完全存在。
根据我自己使用 Subversion 的经验，主干是原始的，但不是发布版本的来源。相反，主干是版本之间的反向和转发端口流动的地方。发布来自版本分支。
从版本分支中，有时会创建功能分支。这些分支允许频繁提交可能会破坏事情。一旦一个特性分支完成，它就会被合并到版本中；当这种整合发生时，不可避免地会有问题需要解决。最后，一旦构建并验证了一个版本，它就会合并到主干中。
所以我认为#1 是不现实的。至于＃2，这取决于。B 和 C 不会改变 A 似乎是确定的吗？如果是这样，则合并 A，然后为 B 和 C 分支。但很可能我会分支 A 来生成 B 和 C，因为后者很可能会改变前者。然后一旦完成，将所有三个卷起来。