我正试图实现gitflow分支策略，并试图了解如何解决我所面临的问题。如果你认为有更好的分支策略可以解决这个问题，请告诉我。
如何处理并行发行
让我们考虑两个团队正在开发两个版本。每个开发人员从开发分支创建功能分支。
功能f_1和f_2是同一个release (release_f)的一部分，然而n_2功能是不同的release (release_n)的一部分，team_2正在开发它。
develop
--feature/f_1 (team_1/dev_1)
--feature/f_2 (team_1/dev_2)
--feature/n_1 (team_2/dev_1)
然而，在融入发展的同时。这发生了。
0.0.1------f_1-----n_1----f2--
现在我如何创建两个不同的版本，这样release_f包含f_1和f_2，或者排除n_1，因为release_n还没有完全准备好进行测试。
虽然gitflow被广泛使用，但很多人都在批评它。在我看来，这是有原因的。它太复杂，适应性差。
因此，在您的情况下，develop分支包含两个版本所基于的公共基础。然后，您的策略将是从develop创建一个分支release_f，其中f_1和f_2被合并为另一个分支release_n，其中n_1被合并为develop。这是主要的核心结构。
还有一些细节问题只有通过对产品本身的具体了解才能回答，例如x_3和y_5是否也应该合并到release_f和/或release_n中?发布分支中的哪些特性也应该合并到develop分支中?某些功能是否可以启用/禁用带有功能标志的编译时(例如#ifdef)?等。
所以我的建议是(简单地)看看gitflow，然后看看其他一些策略，然后找到适合你的。从简单的开始，而不是复杂的，你可以(而且很可能应该)以后总是改变。
在我看来，一个合理的分支策略有以下两个关键点:
- 你有一个分支，每次发布时都被标记1。
- 当您需要更新/修复先前发布的版本时，您可以从相应的发布标签创建维护分支。
其余的都是细节。
1注意"一个分支"，而不是"一个分支"。对于不同的版本，它可以是不同的分支。