假设您目前处于某个产品的第3版，因此您的下一个版本是4.但是您的功能开发时间比您的发布周期要长得多，例如在第5版之前就不会准备好，（可能会更长）。在git-flow中处理这个问题的最佳方法是什么？在我看来，这个工作流程并没有真正允许这种事情。在下一个版本发布后，没有真正的发布标记。
在我工作的地方，我们有一个分支用于下一个版本，即上例中的版本/ 4。然后主分支将用于下一个版本，即发布/ 5。将不在版本4但版本5中的功能将在主分支之外开发。 off / 4中的功能分支将合并回发行版/ 4（如果发布版本4将是更新）然后是master，（尽管如果你忘记合并到master中也不是很大的问题因为他们记得的下一个人会为你做这件事。）
当我们进入下一个版本时，我们将再次分支master，即创建一个release / 5分支。发布/ 5中的功能将分支释放/ 5，在发布/ 6中要完成的任何操作都将在主服务器上，依此类推。
我确实喜欢这个场景的工作流程，因为它可以更容易地开发时间密集型功能，但仍然有意识到发布。我对如何使用git-flow的修改来实现策略感兴趣？
答案 0 :(得分：0)
如果可以，您可以考虑使用“ git workflow ”而不是gitflow。
我将其呈现在“Handle git branching for test and production”
我们的想法是在每次发布后重新创建短暂的“next”分支（一个用于v4，一个用于v5或更高版本）。
在其中，您合并了所需的feature分支。但是，如果这些feature分支已为下一个release做好准备，则不会将“next”分支合并到release（就像在合并时{g}一样。{ 1}}到develop）。您将release分支本身合并到feature。
这样，您可以根据需要管理这些长期功能的生命周期，并在您选择的相应（v4，v5，...）下一个分支中与ohter集成进行验证。