37

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

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

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

似乎 这里定义的 git-flow可以回答很多这些问题。我在 Mercurial 中尝试了这种方法，似乎也可以在那里实现这种方法。遗憾的是，此时迁移到 DVCS 是不可能的。

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

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

4

3 回答 3

33

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

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

这是一个想法，它是如何工作的：

  • 假设您正在开发 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标志合并）。

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

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

您首先从主干合并到分支以重新定位您的代码。完成变基后，您可以使用--reintegrate交换机从分支合并回主干。在 1.6 之前，您应该删除分支并重新创建它，因为--reintegrate合并跟踪有点混乱。但是，这已在 1.6.x 及更高版本中得到修复。

于 2012-11-12T19:29:57.693 回答
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手动选择单个提交以从一个分支应用到另一个分支（例如，开发到已发布-xx-tag）。

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

于 2012-11-12T15:09:15.587 回答
1

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

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

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

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

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

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

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

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

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

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

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

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

使用这种方法，您可以获得以下优势：

  • 后备箱很稳定。你总是知道那一刻主干代表什么。

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

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

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

缺点是：

  • 许多分支机构要管理。

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

  • 每次都要解决很多冲突

顺便说一句，这是我使用过的最好的方法，因为它允许您保持对版本的控制。

于 2018-05-26T00:13:13.167 回答