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

【问题标题】：Git workflow with multiple stable branches, syncing with svn具有多个稳定分支的 Git 工作流，与 svn 同步
【发布时间】：2012-03-05 18:41:28
【问题描述】：

我们的项目已经converted从svn到git。开发人员现在使用git-svn，但希望继续利用引擎盖下的更多力量。愿望清单：

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

以下策略会奏效吗？

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

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

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

【问题讨论】：

标签： git continuous-integration git-svn configuration-management git-flow

【解决方案1】：

好吧，一旦您转换为 git，为 SVN 设置一些分支将是相当麻烦的。我认为那些“用户”应该学习或离开。如果你需要 git 的特性来做更好的分支管理，那么无论 S&U 都是正确的解决方案。

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

【讨论】：

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