svn - 是否可以在 Subversion 中使用 git-flow 模型？

Question

我们使用 Subversion，除了像我这样的少数人之外，几乎没有在 Subversion 中进行分支和合并的经验。我的 Subversion 经验仅限于简单的功能分支，其中合并和树冲突虽然并不罕见，但也不是非常难以解决。

鉴于此，我正在帮助管理一个项目，在该项目中，我们目前对主干方法的 promise 根本无法满足我们的需求。我向我的本地化团队介绍了功能分支和合并，我们取得了一些成功。然而，简单的特征分支仍然无法回答我们所有的问题，例如:

我们如何为此版本和后续版本并行开发代码？

什么代码被认为是稳定的？

哪些(正在开发的)代码会进入下一个版本？

哪些(正在开发的)代码将进入后续版本？

我们的测试、验收或生产环境是什么版本的代码？

我们如何将并发开发事件与已知的稳定版本集成，以减少引入错误和不完整的工作？

我们如何为已发布的代码提供热修复？

我们如何从源代码控制中知道当前正在进行哪些开发事件？

我们如何在利用的同时不破坏当前代码库的情况下进行试验或研发？

看来git-flow as defined here回答很多这些问题会大有帮助。我在 Mercurial 中尝试了这种方法，似乎也可以在那里实现这种方法。可悲的是，此时迁移到 DVCS 已不在考虑之列。

但是，由于许多合并和树冲突，我在 Subversion 中模仿这种方法的简短尝试失败了。合并选项和边缘情况众多且令人困惑。

是否可以使用 Subversion 来实现 git-flow如果是这样，疼痛程度是多少？

Answer 1

我们使用所谓的不稳定主干开发方法。这是 Subversion 的创建者在创建 Subversion 时所考虑的开发方法。它简单易行。

您在主干上进行所有开发。因此称为不稳定主干。

当你接近一个版本时，你为那个版本创建一个分支。这个想法是让分支足够晚以保持尽可能短的并行开发，但不要太晚以至于一些开发人员无法完成他们的工作，因为他们不再需要在当前版本上工作，而是需要开始工作下一个版本。在敏捷中，这通常在紧致冲刺之前完成。它通常在发布功能完成时完成，现在您只是在修复错误。

发布发生在分支之外。你标记了分支。如果有需要的补丁，它们会在分支之外完成。

这是它的工作原理:

假设您正在开发 1.2 版。您正在后备箱上工作。现在，您离 1.2 版即将发布的时间越来越近了，而 1.2 版的工作量不足以让您的开发人员忙得不可开交。您为您的版本创建一个 1.2 分支。

现在，仍在开发 1.2 版的人们切换到了 1.2 版分支。同时，致力于 1.3 的开发人员留在主干上。

您现在已准备好发布 1.2 版。您在分支上标记 Release 1.2。分支不会合并回主干。主干适用于 1.3 版。

报告了错误，您希望在 1.2.1 版中修复它们。您继续在 1.2 分支上工作。 1.2.1 不需要新分支。 (您可以在发布之间锁定分支以保持它们的纯净。

当您准备发布 1.3 版时，您重复该过程——分支 1.3 和 1.4 的工作继续在主干上进行。

会有一些合并。它主要是将发布分支上修复的缺陷合并回主干。执行此操作有以下三种选择:

发布后，您将分支上的所有更改合并回主干。很少有跟踪。您只是假设分支上的所有错误修复也适用于主干。

您使用的跟踪系统了解问题可能存在于多个版本中。在这种情况下，您只需将在分支上发现的错误也标记为主干。由于您的问题跟踪系统，您可以挑选适用于主干的更改。

有些网站根本不合并。他们还通过缺陷跟踪系统跟踪需要应用到分支上的主干的更改，并简单地重新实现它们。他们可能会将更改从分支复制到主干，但他们从不进行正式合并。然而，一旦你这样做，你就永远不能合并(除非你合并了 --record-only 标志)。

当然，您会意识到这种方法需要一些称为计划的东西。您必须优先考虑您的工作，以便开发人员在为 future 版本工作之前先为即将发布的版本工作。只有在即将发布的版本上不再有足够的工作来让所有开发人员忙碌时，您才分支。

您可以实现标准 Git 工作流程，该工作流程为每个开发人员或问题使用单独的开发分支，然后将这些更改交付到主干上。这将需要很多分支，每个开发人员/功能一个。

您首先从主干合并到分支以重新设置代码。完成 rebase 后，您可以使用 --reintegrate 从分支合并回主干。转变。在 1.6 之前，您应该删除分支并重新创建它，因为 --reintegrate有点搞砸了合并跟踪。但是，这已在 1.6.x 版及更高版本中得到修复。