project-management - 有关任务驱动分支的问题

Question

我正在考虑从HG切换到Plastic SCM（http://www.plasticscm.com，主要是因为它似乎提供了更好的VS集成），并且它们促进了“任务驱动的分支”，即从主线分支为每个功能。这是有道理的，但是，我有几个问题：


他们建议不要在完成任务后将您的任务合并回主线。这似乎是非常不直观的，我本以为经过测试后，一个人想立即合并到小费，这样您以后就不必再依靠了。更不用说，如果任务没有合并，并且说要发布一个新版本，则需要合并可能在数百个不同的分支中，并确保它们在短时间内相互兼容（测试）独立并不意味着他们会和别人一起玩，恕我直言）。所以，这似乎注定要失败，我错了吗？你练习这种方法吗？
假设在以下情况下，我在上述情况上是错误的：任务A，B，C。如果B，C依赖于A的完成，那么最好完成A，然后将其合并回主线，然后从那里分支以进行B / C，或者分支您的初始分支（为A创建的分支）。那有可能吗？推荐的？如果同一个人正在实现A，B，C，那么我的脑海中似乎会变得更干净。显然，如果没有实现，那么合并回主线是最有意义的。


让我知道你们的想法！

谢谢。

Answer 1

在我们最近关于分支策略的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等），开发人员可以从干净存储库中进行更新以在开发时保持最新状态。不过，显然，它们将必须在合并之前立即从脏存储库中进行更新。