处理当前发行版中不会出现的特性

Question

假设您目前处于产品的第3版，所以您的下一个版本是4，但是您的特性要比发布周期长得多，例如，要到版本5才能准备好(可能会更长)。在git流中处理这个问题的最好方法是什么？在我看来，这种工作流程不允许这样的事情发生。下一个版本之后没有真正的版本表示法。

在我过去工作的地方，我们为下一个版本提供了一个分支，即上面的示例中的release/4。并且主分支将在该版本之后的下一个版本，即版本/5。特性将不在版本4中，但版本5将从主分支开发出来。释放/4的特性分支将被合并回版本/4(如果版本4已经发布，这将是一个更新)，然后合并到master (虽然如果忘记合并到master中也不是什么大问题，因为如果他们记得下一个人会为您做这件事)。

当我们转移到下一个版本时，我们将再次脱离主版，即创建一个版本/5分支。要发布/5中的特性已经脱离了版本/5，在版本/6中要做的任何事情都将在主服务器上完成，等等。

对于这个场景，我确实喜欢这个工作流，因为它使开发时间密集型功能变得更容易，但仍然有意识到发布的意图。我感兴趣的策略是如何通过修改git流来实现这一点？

Answer 1

如果可以，可以考虑使用"git工作流“而不是gitflow。

我把它写在"Handle git branching for test and production“里

其想法是拥有短暂的“next”分支(一个用于v4，一个用于v5或更高版本)，在每次发布后重新创建。

在它们中，合并您想要的feature分支。但是，如果这些feature分支已经为下一个release做好了准备，那么就不会将'next‘分支合并到release (就像将develop合并到release时在gitflow中所做的那样)。将feature分支本身合并到release。

这样，您可以根据需要管理这些长期特性的生命周期，并在适当的时候与ohter集成来验证它们(v4、v5、.)你选择的下一个分支。