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

Question

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

鉴于此，我正在帮助管理一个项目，我们当前对trunk方法的提交根本不可持续地满足我们的需求。我介绍了功能分支和合并到我的本地化团队，我们取得了一些成功。然而，简单的功能分支仍然无法回答我们的所有问题，例如：

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

似乎git-flow as defined here可以解决很多这些问题。我在Mercurial中尝试了这个方法，似乎也可以在那里实现这个方法。遗憾的是，此时迁移到DVCS已不在考虑范围内。

但是，我在Subversion中模仿此方法的简短尝试失败了许多合并和树冲突。合并选项和边缘情况很多，令人费解。

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

Answer 1

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

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

以下是一个如何运作的想法：

• 想象一下，你正在开发1.2版本。你正在上行李箱。现在，您已接近即将发布版本1.2的时间，并且在版本1.2上没有足够的工作来让您的开发人员忙碌。您为发布创建了一个1.2分支。
• 现在，仍在使用版本1.2的人员切换到版本1.2分支。同时，处理1.3的开发人员仍然留在 trunk 。
• 您现在已准备好发布1.2版。您可以在分支上标记版本1.2。分支未合并回主干。主干用于版本1.3。
• 报告了错误，您希望在版本1.2.1中修复它们。你继续在1.2分支机构工作。 1.2.1不需要新分支。 （您可以在版本之间锁定分支以使它们纯。
• 当您即将执行版本1.3时，您将重复此过程 - 分支1.3并继续在主干上继续工作。

会有一些合并。它主要是将发布分支上固定的缺陷合并到主干上。这样做有三种选择：

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

当然，您意识到此方法采用了名为规划的方法。您必须优先考虑您的工作，以便开发人员在为将来的版本工作之前完成即将发布的版本的工作。只有在即将发布的版本中没有足够的工作才能让所有开发人员忙碌时，才会进行分支。

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

首先从主干到分支合并到 rebase 您的代码。完成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 overview）
9. 再次使用本地副本我害怕/或分支。或者让R＆amp; D在本地使用git svn进行研究。

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

这就是我现在想出来的所有内容，希望它有所帮助。

Answer 3

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

1. Trunk是“主”分支。你不应该直接在trunk中提交任何东西。 Trunk始终需要与生产中最新发布的版本完全匹配。 因此，trunk始终代表一个稳定的分支。 只有重新整合分支才会更新中继。

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

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

   • 开发：旨在用于未计划发布的未来发展。
   • 修补程序：用于提交所有错误修复，只修复。对于频繁使用，需要在更新中继时使用中继版本进行更新。

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

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

6. 从集成分支或分支自我构建工件。

7. 当您发布分支时，请为该版本创建标记，以便您可以获得已发布版本的副本，并且仍然可以使用该分支。 在标签中，您应该只发布版本。不要在标签中提交更改！

8. 分支发布后，您需要更新主干。因此，重新整合树干中的分支。您可以直接重新集成集成分支或分支（如果您没有从集成中传递）。

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

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

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

• 行李箱稳定。你总是知道当时干线代表什么。

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

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

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

缺点是：

• 要管理的许多分支机构。

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

• 每次都要解决许多冲突

顺便说一句，这是我曾经使用过的最佳方法，因为它可以让你控制版本。