开源项目的Git分支模型

Question

我们正在开发一个使用多个版本分支的开源项目：

Ex：master，1.1（lts），1.2，1.3（lts），2.0 ....

我们在生产中使用之前的LTS，以便拥有最稳定的分支。

我们的问题：

我们正在1.1，并且有数百次提交。 （未上游的PR，或内部变化）。我们需要转移到1.3

每3个月有一个新版本的分支。因此，这个过程必须尽可能轻松有效

可能的解决方案：

• 将1.1合并到1.3。由于这两棵树有一个很长的分叉树，我不确定它是否是最好的方法
• Cherry从1.1到1.3选择我们的提交。不确定这是最好的主意，因为我们必须从版本到版本挑选所有这些提交。

您有任何建议或建议吗？

由于

Answer 1

您可以在master和发布分支之间建立一个“staging”分支吗？

请参阅git flow，他们称之为staging branch develop： https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow

Answer 2

一年多之后，发布了许多版本，我们最终完成了以下操作：

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

当需要切换到新分支时，我们正在对新版本上的先前分支所做的修改。

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