是否可以将 git-flow 模型与 Subversion 一起使用？

Question

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

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

1. 我们如何为这个版本和后续版本并行开发代码？
2. 什么代码被认为是稳定的？
3. 下一个版本中将包含哪些（开发中的）代码？
4. 后续版本中将包含哪些（开发中的）代码？
5. 我们的测试、验收或生产环境是什么版本的代码？
6. 我们如何将并发开发活动与已知稳定版本集成，以减少引入错误和不完整的工作？
7. 我们如何为已发布的代码提供热修复？
8. 我们如何通过源代码控制了解当前正在进行的开发活动？
9. 我们如何在不破坏当前代码库的情况下进行实验或研发？

似乎git-flow as defined here 可以回答很多这些问题。我在 Mercurial 中尝试了这种方法，似乎也可以在那里实现这种方法。遗憾的是，目前无法迁移到 DVCS。

但是，我在 Subversion 中模仿这种方法的短暂尝试失败了，因为许多合并和树冲突。合并选项和边缘情况众多且令人费解。

可以使用 Subversion 来实现git-flow，如果可以，痛苦程度如何？

Answer 1

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

• 您在 trunk 上完成所有开发工作。因此称为不稳定的主干。
• 当您接近某个版本时，您会为该版本创建一个分支。这个想法是让分支足够晚以保持并行开发尽可能短，但不会太晚以至于一些开发人员无法完成他们的工作，因为他们不再需要在当前版本上工作，而是需要开始在下一个版本。在敏捷中，这通常在坚定 sprint 之前完成。它通常在发布功能完成时完成，而现在您只是在修复错误。
• 发布发生在分支之外。你标记了分支。如果有需要的补丁，它们会在分支之外完成。

下面是它的工作原理：

• 假设您正在开发 1.2 版。你正在干线工作。现在，您即将发布 1.2 版，而 1.2 版的工作还不足以让您的开发人员忙得不可开交。您为您的版本创建一个 1.2 分支。
• 现在，仍在开发 1.2 版的人员切换到 1.2 版分支。同时，开发 1.3 的开发人员仍留在 trunk。
• 您现在已准备好发布 1.2。您在分支上标记 Release 1.2。分支不会合并回主干。主干适用于 1.3 版。
• 报告了错误，您希望在版本 1.2.1 中修复它们。您继续在 1.2 分支上工作。 1.2.1 不需要新的分支。 （您可以在版本之间锁定分支以保持它们纯粹。
• 当您即将发布 1.3 版时，请重复该过程 -- 分支 1.3 并在主干上继续为 1.4 工作。

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

• 发布后，将分支上的所有更改合并回主干。很少有人跟踪。您只是假设分支上的所有错误修复也适用于主干。
• 您使用的跟踪系统了解问题可能存在于多个版本中。在这种情况下，您只需将在分支上发现的错误也标记到主干。借助您的问题跟踪系统，您可以挑选适用于主干的更改。
• 有些网站根本不合并。他们还通过缺陷跟踪系统跟踪需要应用于分支上的主干的更改，并简单地重新实现它们。他们可能会将更改从分支复制到主干，但他们从不进行正式合并。但是，一旦您这样做了，就永远无法合并（除非您与 --record-only 标志合并）。

当然，您会意识到这个方法需要一个叫做planning的东西。您必须优先考虑您的工作，以便开发人员在处理未来版本之前为即将发布的版本完成工作。只有在即将发布的版本上没有足够的工作来让所有开发人员忙于工作时，您才需要进行分支。

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

您首先从主干合并到分支以 rebase 您的代码。完成变基后，使用--reintegrate 开关从分支合并回主干。在 1.6 之前，您应该删除分支并重新创建它，因为 --reintegrate 有点搞砸了合并跟踪。不过，此问题已在 1.6.x 及更高版本中得到修复。

Answer 2

这是个大问题。我只知道如何解决一些问题：

1. 我认为如果不大量使用分支就很难解决这个问题。不确定这是否可以通过使用 GIT 轻松解决。功能分支在解决这个问题方面大有帮助，但一般来说，您可能应该尝试只专注于下一个版本的功能。
2. trunk - 我认为它是 master 分支。
3. 我会说development 分支是下一个版本的代码
4. 如果不使用很多分支似乎很困难，不知道如何正确解决这个问题。
5. 您可以使用分支或记下 TEST 和 ACC 中的修订号。我猜应该将 PROD 放入标签中。
6. 我想说的是使用自动化回归测试和持续集成。在这里使用同行评审也可以提供帮助，充其量您使用某种工具将文件标记为已审核。这样，您可以确保仅合并已审核的文件。将您的提交消息绑定到您的错误跟踪器也可能很有趣，以自动找出与哪些问题相关的哪些文件已被触及，然后确保对于您要合并的文件实际上已关闭所有问题。这是一项非常重要的任务，尤其是当您正在考虑仅合并部分分支时。因此，在某种程度上，进行了特征合并。
7. 为发布使用标签。您可以像分支一样检查它并在必要时添加补丁
8. 在一页上列出整个存储库的所有 svn 提交（例如 trac/redmine/jira 概述）
9. 恐怕再次使用本地副本/或分支。或者让研发在本地使用 git svn 进行研究。

其中一些问题可以通过使用git svn 至少部分解决。例如，通过使用它，您可以使用 gits 分支功能在本地进行实验，而无需将它们存储在全局存储库中。当然，如果您正在与团队中的许多成员一起探索一个新功能，这并不有趣，除非他们都对使用 git 并通过网络相互拉取感到满意。 通过使用git svn，您还可以使用git cherrypick 手动选择单个提交以从一个分支应用到另一个分支（例如，开发到released-x.x-tag）。

暂时就想到这么多，希望对你有帮助。

Answer 3

在我的活动中，我通过以下方法使用 SVN。

1. Trunk 是“主”分支。你永远不应该直接在主干中提交任何东西。 Trunk 总是需要与生产中最新发布的版本完全匹配。 所以，主干总是代表一个稳定的分支。 仅在重新集成分支时才更新主干。

2. 您的工作需要分支。每个新分支都必须从主干创建，因此每个新分支在创建时都与生产版本完全匹配。 更改和修复在分支中提交。

3. 你应该至少有 2 个主要分支：

   • develop：用于尚未计划发布的未来开发。
   • hotfix: 用于提交所有错误修复和仅修复。频繁使用，更新trunk时需要更新trunk版本。

4. 为每个主要工作流创建一个分支：一个项目、一个子项目、一个变更请求。您可以进行并行开发。

5. 创建“集成”分支以加入您必须发布的分支。您需要将每个候选发布的分支合并到集成分支中。 因此，集成分支可以同时加入修补程序和项目。

6. 从集成分支或分支自身构建您的工件。

7. 发布分支后，为该版本创建标签，这样您就可以拥有已发布版本的副本并且仍然可以使用该分支。 在标签中，您应该只有发布版本。不要在标签中提交更改！

8. 分支发布后，需要更新主干。所以重新整合主干中的分支。您可以重新集成集成分支，也可以直接重新集成分支（如果您没有通过集成）。

9. 当主干再次与生产版本匹配时，在所有活动分支中报告。

这种方法并不是真正的 git-flow 概念的复制品，但它遵循了它的一些要求。

通过这种方法，您可以获得以下优势：

• 主干稳定。在那一刻你总是知道树干代表什么。

• 每个分支只包含自己的更改。

• 借助集成分支，您可以在单个版本中管理并行分支

• 使用标签，您始终拥有已发布版本的副本

缺点是：

• 要管理许多分支机构。

• 您需要经常合并和切换，尤其是要将更改报告到集成分支中

• 每次都要解决很多冲突

顺便说一句，这是我用过的最好的方法，因为它可以让你保持对版本的控制。