Git 开源项目的分支模型

Question

我们正在使用多个版本分支的开源项目之上进行开发：

例如：master、1.1 (lts)、1.2、1.3 (lts)、2.0 ....

我们在生产环境中使用之前的 LTS 以获得最稳定的分支。

我们的问题：

我们目前正在 1.1 并且有数百个提交。 （未合并的上游 PR，或内部更改）。我们需要搬到 1.3

每3个月有一个新的版本分支。所以这个过程必须尽可能无痛和高效

可能的解决方案：

• 正在将 1.1 合并到 1.3。由于这两棵树有一个很长的分叉树，我不确定这是不是最好的方法
• 樱桃挑选我们从 1.1 到 1.3 的提交。不确定这是最好的主意，因为我们将不得不从一个版本到另一个版本挑选所有这些提交。

您有什么意见或建议吗？

谢谢

Answer 1

你能不能在 master 和发布分支之间有一个更频繁同步的 "staging" 分支？

查看 git 流程，他们称之为暂存分支 develop： https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow

Answer 2

经过一年多的发布，我们最终完成了以下工作：

首先，我们通过使用更合适的可用扩展点来避免对存储库进行更改。这将合并的复杂性降低了 90%。

当需要切换到新分支时，我们会在新版本上对之前的分支更改进行精选。

此解决方案的效果比最初预期的要好得多。当发生冲突时，它们很容易修复，并且由于我们对这个存储库的大部分更改也通过 PR 提交到上游项目，因此实际增量随着时间的推移越来越小。