2

我们的项目已经从 svn转换为 git。开发人员现在正在使用git-svn，但希望继续利用引擎盖下的更多功能。愿望清单：

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

以下策略会奏效吗？

  1. 开发：进行开发的主线分支，a'la git-flow
  2. 稳定的产品分支：product1 .. product3。其中一个或多个将在开发版本发布时从主线合并。似乎类似于 git flow 中的“发布开始 1.4.3”，但这些将是永久分支。版本将在此处标记，然后合并回开发。这一点它会很稳定，就像 git-flow 中的 master 一样，只有几个。
  3. 停止直接使用 git-svn - 改为推/拉到镜像。如果需要，还可以使用功能分支
  4. 合并 svn/trunk -> 开发。Svn 会得到偶尔和孤立的签入；因此计划通过 Jenkins 工作将其自动化，如果失败则通知人们以便可以手动合并
  5. 合并开发-> svn/trunk：定期（例如每天），以批处理模式。这可能是最不稳定的部分（至少对于新手来说）。计划诸如变基或一些重置巫术之类的事情
  6. CI 设置很简单，例如测试和开发从主线构建，官方产品从他们自己的产品分支构建

Git-Flow很诱人——主要是因为它被很好地描述和自动化。但这似乎并不适合我的情况。主要是由于潜在的并行发布、多个产品线和CI 方面。

任何知情意见将不胜感激。

4

1 回答 1

3

好吧，一旦您转换为 git，为 SVN 设置一些分支将是非常困难的。我认为那些“用户”应该学习或离开。如果您需要 git 的功能来更好地进行分支管理，那么无论 S&U 是什么，它都是正确的解决方案。

在管理多个生产版本方面，我将为您提供我为Net-SNMP提出的运行良好的模型。我们有许多生产版本的分支，它们维护了很多年，因此在 SVN 下跟踪补丁一直是一件痛苦的事。在我们新的Workflow下，我们更快乐，并且通常有足够好的感觉，我们没有因为真正的合并而将补丁放到某个或另一个分支（与 SVN 不同，我们必须手动确保每个分支都包含每个补丁）。

于 2012-03-05T19:25:18.490 回答