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

Question

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

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

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

似乎 这里定义的git-flow将很长一段时间来回答很多这些问题.我在Mercurial中尝试了这个方法,似乎也可以在那里实现这个方法.可悲的是,此时迁移到DVCS已不在考虑范围之内.

但是,我在Subversion中模仿此方法的简短尝试因许多合并和树冲突而失败.合并选项和边缘案例众多且令人费解.

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

Answer 1

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

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

这是一个如何工作的想法:

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

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

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

当然,你意识到这种方法需要采取一种称为计划的方法.您必须优先考虑您的工作,以便开发人员在为将来的版本工作之前完成即将发布的版本的工作.只有在即将发布的版本中没有足够的工作才能让所有开发人员忙碌时,才能进行分支.

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

你第一次从主干合并到分支衍合你的代码.完成rebase后,使用--reintegrate交换机将分支合并回主干.1.6之前的版本,您可能会删除分支并重新创建它,因为它--reintegrate有一些混乱的合并跟踪.但是,已在版本1.6.x及更高版本中修复此问题.