gitflow 与 bitbucket 的分支策略

Question

我正在尝试实施 gitflow 分支策略并尝试了解如何解决我面临的问题。如果您认为有更好的分支策略可以解决这个问题，请告诉我。

如何处理并行发布

让我们考虑两个团队正在开发两个版本。每个开发人员都从开发分支创建了功能分支。
功能

f_1

和

f_2

是相同

release (release_f)

的一部分，但是

n_2

功能是 team_2 正在开发的不同

release (release_n)

的一部分。

develop
    --feature/f_1 (team_1/dev_1)
    --feature/f_2 (team_1/dev_2)
    --feature/n_1 (team_2/dev_1)

但是，在合并到develop的同时。这件事发生了。

0.0.1------f_1-----n_1----f2--

现在如何创建两个不同的版本，以便

release_f

包含

f_1

和

f_2

或排除

n_1

，因为

release_n

尚未完全准备好进行测试。

Answer 1

虽然 gitflow 很常用，但 many people are criticizing 它。我认为这是有充分理由的。太复杂，适应性不强。

因此，在您的情况下，

develop

分支包含两个版本所基于的共同基础。然后，您的策略将是从 f_1 和 f_2 合并到的

release_f

创建一个分支

develop

，并从 n_1 合并到的

release_n

创建另一个分支

develop

。这就是主要的核心结构。

还有一些细节只能通过产品本身的具体知识才能回答，例如： x_3 和 y_5 是否也应该合并到

release_f

和/或

release_n

中？发布分支中的哪些功能也应该合并到

develop

分支中？某些功能是否可以通过功能标志启用/禁用编译时（例如

#ifdef

）？等等

所以我的建议是（简单地）看看 gitflow，然后研究一些其他策略，然后找到适合你的策略。开始时比较简单而不是复杂，您可以（并且很可能应该）稍后进行更改。

我认为，健全的分支策略的两个关键点如下：

剩下的就是细节了。

¹ 注意“一个分支”，而不是“一个分支”。不同的版本可以是不同的分支。