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

Question

从svn到git，我们的项目已经converted。开发人员现在正在使用git-svn，但我想这样做 继续利用引擎盖下的更多动力。的收藏：

• 强大的分支，例如主题/功能分支
• 主要版本和暂存版本之间的隔离，有时是多个并行。
• 精益＆amp;平均且稳定的Jenkins-CI设置 - 最小化维护（与每次发布后更改作业配置相比）
• 短暂的迭代，开发团队每两周向QA发布一次;
• 从同一来源建造的多种产品（P1..P3），独立发布;压力不一。
• 在“更大团队”中有更多的休闲，非git用户......他们是S&U :) ..但我们必须给他们svn访问至少1个分支（主干）。他们的贡献受到一些限制，所以这里没有太大的风险。

以下策略是否有效？

1. 开发：发展发生的主线分支，a'la git-flow
2. 稳定的产品分支：product1 .. product3。这些中的一个或多个将在dev发布时从主线获得合并。似乎与git flow中的'release start 1.4.3'类似 - 但这些将是永久分支。发布将在此标记，然后合并回发展。这一点它会稳定，就像git-flow中的master一样，只有几个。
3. 直接停止使用git-svn - 推送/拉动镜子。如果需要，还可以使用功能分支
4. 合并svn / trunk - ＆gt;开发。 Svn会偶尔办理入住手续;因此计划通过Jenkins工作自动化它，通知人们是否失败以便可以手动合并
5. 合并开发 - > svn / trunk：定期（例如每天），以批处理模式。这可能是最不稳定的部分（至少对新手来说）。规划rebase or some reset wizardy
之类的东西
6. CI设置很简单，例如test和dev建立主线，官方产品建立自己的产品分支

Git-Flow很诱人 - 主要是因为它很好地描述和自动化。但它似乎不适合我的情况;主要是由于可能的并行版本，多个产品系列和CI aspects。

非常感谢任何知情意见。

Answer 1

好吧，一旦你转换为git，为SVN设置一些分支将是非常hacky。我认为那些“用户”应该学习或消失。如果您需要git的功能来进行更好的分支管理，那么无论S＆amp; U如何，它都是正确的解决方案。

在管理多个生产版本方面，我将为您提供我为Net-SNMP提出的非常有效的模型。我们有许多生产版本的分支，这些分支可以维护多年，因此跟踪补丁在SVN下总是很痛苦。在我们新的Workflow下，我们感到非常高兴并且通常有足够好的感觉，因为我们没有因为真正的合并而将补丁丢弃到某个分支或另一个分支（与SVN相反，我们不得不手动确保每一个分支包含每个补丁）。