我一直在阅读git分支工作流程，似乎有一个假设，即分支机构用于开发目的，最终将所有内容合并回主服务器。关于使用长期运行的分支来维护旧版本，我找不到太多讨论。
例如，以下是我的工作流程在SVN中的工作原理（基于perforce“豆腐”模型）。假设最新发布的版本是4.1，但我也支持版本4.0,3.5和3.6，因此每个版本都有一个维护分支。 Trunk用于4.2版之前不会发布的功能。现在说客户需要修复版本3.6的错误。我将修复我的3.6维护分支并进行新的维护版本（为了参数，3.6.22）。
此时修复程序向下合并到4.0并从那里合并到4.1,4.2和trunk，然后从那里合并到由trunk创建的任何开发分支中。请注意，这不是一个挑选合并;这是一个正常的SVN自动合并。
如果修复程序不重要，我们可能会从3.6版本分支创建一个dev分支，然后在发布之前以正常方式重新集成它。类似地，如果合并到4.1是非常重要的，我们可能会从4.1合并到一个开发分支，然后在我们对合并感到满意时将其重新集成到4.1版本中。
当我们发布版本4.2时，我们将以相同的方式分支维护分支，并且trunk将成为正在进行的4.3工作
我是否（甚至可以）在git中使用完全相同的工作流程，还是需要重新考虑这种“老式”传统的svn思维？
答案 0 :(得分：3)
分支策略实际上并没有太大变化，具体取决于版本控制技术。您所描述的内容听起来像是实时产品的标准分支工作流程。从SVN等其他工具迁移到Git的变化是创建和维护分支的成本。在Git中，分支非常便宜。 Git中的一个分支基本上只是一个指向提交的指针。因此，例如，创建仅包含少量提交的维护分支的成本将逐渐增加。对于像SVN这样的工具可能不是这种情况，可能需要创建项目中的副本或每个文件。