我正在考虑从HG切换到Plastic SCM（http://www.plasticscm.com，主要是因为它似乎提供了更好的VS集成），并且它们促进了“任务驱动的分支”，即从每条特征的主线分支。这是有道理的，但是，我有几个问题：
让我知道你们的想法！
感谢。
答案 0 :(得分：2)
在我们最近的rather good discussion分支策略中，jgifford25's answer包含一个指向Subversion开发人员称之为“agile release strategy”的链接，它看起来与Plastic的相似伙计们建议 - 每个功能的分支，合并到发布分支而不是进入主干。我认为这不是一个好主意，我认为这不是一个好主意。在这两种情况下，我都认为这个想法是由SCM开发人员推动的 - 我认为这些人有一个“一切看起来像钉子”的情况，并且认为任何流程问题都可以通过更多修复更大的SCM。
那为什么这个想法不好？让我们按照塑料人的说法。他们围绕一个中心思想建立这个过程：'保持主线原始'。到现在为止还挺好。然后，他们推进了一个看似如下的三段论：
这个问题是它完全误解为什么破坏的构建是坏的。破碎的构建本身并不坏（尽管它们没有用，因为它们阻碍了开发），它们很糟糕，因为它们意味着有人已经检查了破碎的代码。这是破碎的代码，这是真正的问题，而不是破坏的构建 - 它是破碎的代码，实际上有可能造成损害（丢失用户数据，丢失空间探测，全球热核战争，那种事情）。
然后，他们的解决方案相当于让人们在别处检查他们破坏的代码，这样它就不会破坏构建。这显然没有什么可以处理破坏代码的实际问题 - 恰恰相反，它是隐藏破坏代码的一种方式。实际上，我不清楚在何时检测到破坏 - 当任务分支最终确定并合并到发布分支时？这听起来像是一个很好的方法，可以在你的发布周期推迟困难的工作，这是一个非常糟糕的主意。
真正的解决方案很简单，就是根本不检查损坏的代码。在追求这个目标的过程中，破坏的构建实际上是好，因为它告诉您存在破坏的代码，可以让您修复它。事实上，这是持续集成概念的整个翻转点 - 您需要尽早合并并经常合并到单个主干中，这是实际发布内容的原型，因此您可以检测到您最早要发布的内容的问题。可能。这绝对需要“不稳定的主干”模型，或者与它同构的东西。
blog post链接的orangepips's answer提到了Ubuntu关于流程的想法，作为此想法的驱动因素。但看看沙特尔沃思实际上说的是什么：
这是我对最后一点的强调，但这是Shuttleworth的最终目标：他希望能够随时减少发布。像Plastic模型那样，将合并和测试推迟到发布过程的过程不可能做到这一点。
相反，如果你想查看一个可以做到的过程是什么样子，请查看what the lean guys do：一个代码行，持续集成（按小时甚至几分钟，而不是几天或几周），没有破码。
所以，总之：不要这样做。有一个代码行，并尽可能多地检查工作代码。简单。
PS好的，所以你可能想要发布分支来稳定和修复实际版本。理想情况下，你不会，但你可能需要。
PPS如果您的CI测试套件在签入之前运行速度太慢（例如需要一小时的功能测试），那么您可以对任何DVCS执行的操作都有两个存储库：一个脏的，开发人员合并到一个干净的，由一个脚本推送到一个脚本，该脚本监视脏存储库的变化，构建和测试进入它的新版本，如果它们通过则推送到干净的存储库。然后，您可以从干净的存储库运行按需发布（对于QA等），开发人员可以从干净的存储库进行更新，以便在开发时保持最新状态。但是，他们显然必须在合并之前立即从脏存储库进行更新。
答案 1 :(得分：0)
在reading the PR之后，听起来好像他们提倡code is tested before it's merged into the trunk/main/base-line的模型（参见规则＃4）。这预先假定了一系列单元测试和，这些测试涵盖了所做的任何更改。对于我参与的大多数项目，套件不存在，可能永远不会完全。
根据我自己使用Subversion的经验，主干是原始的，但不是发布的版本。相反，trunk是版本流之间的后向和前向端口。版本来自版本分支。
从版本分支创建功能分支 - 有时。这些分支允许频繁提交可能会破坏事物。功能分支完成后，它就会合并到版本中;当这种集成发生时，不可避免地要解决问题。最后，一旦构建并验证了一个版本，它就会合并到主干中。
所以我认为＃1不太现实。至于＃2，它取决于。似乎可以肯定B和C不会改变A吗？如果是这样的话，合并A然后分支B和C.但我很可能会将A分支制作B和C，因为后者可能会改变前者。然后一旦完成，将所有三个卷起来。