具有多个稳定分支的Git工作流，与svn同步

我们的项目已经从svn到git。开发人员现在使用的是

gitsvn

，但希望 继续，在发动机罩下利用更多的动力。愿望清单：

• 强大的分支，例如主题/功能分支
• 主线和发布阶段工作之间的隔离，有时是多个并行的
• 精简、平均和稳定的Jenkins CI设置-最少维护（与每次发布后更改作业配置相比）
• 短期迭代，开发团队每2周向QA发布一次；不一定在外面
• 从相同来源构建的多个产品（P1..P3），独立发布；变压
• 在“更伟大的团队”中有更多非正式的非git用户…他们是：）。。但我们必须给他们至少一个分支（主干）的svn访问权。他们的贡献被限制在几个目录中，因此这里没有太多的确定风险

以下策略有效吗

开发：开发发生的主线分支，a'la git flow

稳定的产品分支：产品1。。产品3。在dev发布时，其中一个或多个将从主线获得合并。看起来类似于git flow中的“release start 1.4.3”，但这些将是永久分支。发行版将在这里标记，然后合并回开发。在这一点上，它将是稳定的，就像git流中的master一样，只是其中的几个

停止直接使用git svn-改为推/拉镜像。如果需要，还可以使用要素分支

合并svn/主干->开发。Svn将获得偶尔和单独的签入；因此，计划通过Jenkins job实现自动化，并在失败时通知人们，以便手动合并

合并开发->svn/主干：定期（如每天），以批处理模式。这可能是最不可靠的部分（至少对新手来说）。像这样的计划

CI设置将非常简单，例如，测试和开发构建脱离主线，官方产品构建脱离自己的产品分支

很吸引人-主要是因为它被很好地描述和自动化。但这似乎并不完全符合我的情况；主要是由于潜在的并行发布、多个产品线和

---

如果您有任何明智的意见，我们将不胜感激。

好吧，一旦您转换为git，为SVN建立一些分支机构将是非常困难的。我认为这些“用户”要么学习，要么离开。如果您需要git的特性来更好地进行分支管理，那么无论s&U如何，它都是正确的解决方案

---

在管理多个生产版本方面，我将为您提供我为其设计的模型，该模型非常有效。我们有许多生产版本的分支，这些分支已经维护了很多年，因此跟踪补丁在SVN下总是一件痛苦的事情。在我们的新版本中，我们会更快乐，并且通常有足够好的感觉，因为真正的合并（与SVN不同，我们必须手动确保每个分支都包含每个补丁）。

在SVN->git同步（第4点）中，再次说明：听起来很简单：一个简单的合并。另一方面（#5）则不那么重要——需要让历史线性化。。它本质上与git svn相同（我以前也在那里进行复杂的合并），只是在团队级别。IMHO的关键是要定期、始终如一地这样做。除了政治之外，你还期待什么样的痛苦？（即使我同意人们应该乐于学习，他们也会争辩说现在没有时间，而且我更喜欢逐步推出，而不是混入政治）。感谢分享您的工作流程，级联发布分支和瀑布合并很有趣，即使不适用于我的环境。在您的情况下，发布分支似乎是为了维护的目的，在我看来，它们更适合并行推出/硬化+提供一个干净的、产品集中的历史。如果您的分支是真正并行的，那么考虑尽可能多地使用特征分支，并有一个需要哪些产品进入哪些分支的列表，基本上，他们会在某一点上获得所有的功能，只是在一个可能不同的周期中。。例如，当P1-V1.4推出（稳定阶段）时，我们希望保护P1分支不受P3-V1.7相关工作或一般基础工作的影响，但这将尽快得到它们（例如下一次迭代）。顺便说一句，软件体系结构是模块化的（OSGi），所以只有一个源代码并不意味着所有产品构建都包含所有功能。。但消息来源确实如此。