處理當前版本中不會包含的功能

Question

假設您目前處於產品的第3版，並且您的下一個版本爲4.但是您的功能比開發週期需要花費更長的時間，例如不會準備好，直到版本5，（可能會更長）。在git-flow中處理這個問題的最好方法是什麼？在我看來，這種工作流程並不真的允許這樣的事情。在下一個版本之後，沒有真正的發行版本。

在我使用工作的地方，我們有一個下一個版本的分支，例如上面的例子中的release/4。並且主分支將在下一個版本之後發佈，即版本/ 5。不會在版本4但版本5的功能將在主分支上開發。功能分支發佈/ 4將合併回發佈/ 4（這將是一個更新，如果版本4已經發布），然後掌握（儘管如果你忘記合併到主控中也不是什麼大問題，因爲如果他們記得下一個人會爲你做。）

當我們轉到下一個版本時，我們會再次分出主版本，即創建一個版本/ 5分支。要釋放/ 5中的特性將分支釋放/ 5，釋放/ 6中要做的任何事情都將在主控器上進行，等等。

我確實喜歡這種情況下的工作流程，因爲它使開發時間密集型功能變得更容易，但仍然具有釋放感知的意圖。我對如何通過修改git-flow來實現策略感興趣？

Answer 1

如果可以，您可以考慮使用「git工作流程」而不是gitflow。
我目前它在「Handle git branching for test and production」

的想法是有短暫的「next」分支（一個爲V4，V5一個或更高版本），你每次發佈後重新創建。

在它們中，您合併了您想要的feature分行。但是，如果這些feature分支已準備好用於下一個release，則不會將'next'分支合併到release（就像在合併develop到release時在gitflow中所做的那樣）。您將feature分支本身合併到release。

這樣，您可以根據需要管理這些長期功能的生命週期，並在您選擇的相應（v4，v5，...）下一個分支中與ohter集成來驗證它們。