我们的项目已converted从 svn 到 git。开发人员现在正在使用 git-svn，但希望 继续在引擎盖下利用更多的力量。愿望 list :
- 强大的分支，例如主题/功能分支
- 主线和发布的暂存工作之间的隔离，有时是多个并行的。
- 精益、平均且稳定的 Jenkins-CI 设置 - 最少的维护(与每次发布后更改作业配置相比)
- 迭代时间短，开发团队每两周向 QA 发布一次版本；不一定在外面
- 多个产品(P1..P3)由相同来源构建，独立发布；不同压力下
- “更大的团队”中有更多休闲的非 git 用户......他们是 S&U :)..但是我们必须给他们 svn 访问至少 1 个分支(主干)的权限。他们的贡献仅限于几个方向，因此这里没有太大的冲突风险。
以下策略有效吗？
- develop:进行开发的主线分支，a'la git-flow
- 稳定的产品分支:product1 ..product3。其中一个或多个将在开发版本发布时从主线 merge 。似乎类似于 git flow 中的“release start 1.4.3”，但这些将是永久分支。版本将在此处标记，然后 merge 回开发。到了这一步，它就会变得稳定，就像 git-flow 中的 master 一样，只是其中的几个。
- 停止直接使用 git-svn - 而是推/pull 到镜像。如果需要，还可以使用功能分支
- merge svn/trunk -> 开发。 Svn 会偶尔进行单独的 checkin ；因此计划通过 Jenkins 作业将其自动化，如果失败则通知人们，以便可以手动 merge
- merge develop->svn/trunk:定期(例如每天)，以批处理模式。这可能是最不稳定的部分(至少对于新手来说)。规划类似 rebase or some reset wizardy
- CI 设置很简单，例如测试和开发基于主线构建，官方产品基于自己的产品分支构建
Git-Flow很诱人——主要是因为它有很好的描述和自动化。但这似乎并不适合我的情况；主要是由于潜在的并行版本、多个产品线以及 CI aspects .
任何明智的意见将不胜感激。
最佳答案
嗯，一旦你转换为 git，为 SVN 设置一些分支将是相当困难的。我认为那些“用户”应该学习或离开。如果您需要 git 的功能来更好地进行分支管理，那么无论 S&U 如何，它都是正确的解决方案。
在管理多个生产版本方面，我将向您提供我为 Net-SNMP 提出的模型。效果很好。我们有许多生产版本分支，这些分支维护了很多年，因此在 SVN 下跟踪补丁始终是一件痛苦的事情。根据我们的新Workflow ，我们很高兴，并且通常有足够好的感觉，因为我们没有因为真正的 merge 而将补丁删除到某个分支或另一个分支(与 SVN 不同，在 SVN 中我们必须手动确保每个分支都包含每个补丁)。
关于具有多个稳定分支的 Git 工作流程，与 svn 同步，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9572056/