開源項目上的Git分支模型

Question

我們正在使用多個版本分支的開源項目之上進行開發：

例如： 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和release分支之間有一個“ staging”分支，您可以更頻繁地同步它？

在他們稱為暫存分支的地方查看git flow： https : //www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow

Answer 2

經過一年多的時間，發布了許多版本，我們最終完成了以下工作：

首先，我們避免使用更合適的擴展點來對存儲庫進行更改。 這樣可以將合並的復雜度降低90％。

當需要切換到新分支時，我們正在對新版本上的先前分支所做的修改。

該解決方案比最初預期的要好得多。 當發生沖突時，它們很容易解決，並且由於我們對該存儲庫的大部分更改也都通過PR提交給了上游項目，因此實際增量隨着時間而越來越小。