为什么Git Flow建议将功能分支合并到开发分支而不是发布分支

我们想切换到Git流，但我有一些担心，因为有两个不同的团队使用同一个存储库。 团队A希望使用开发分支进行提交，但是团队B创建了功能分支并在那里工作。团队A应该几乎每周一天进行实时部署，另一方面，团队B为部署准备每周发布包

在这种情况下，我们可能很难将特性分支合并到dev和release分支。这就是为什么我想直接将功能分支合并到发布分支。此外，我们可能需要根据需要暂停发布分支一段时间。但是git flow不建议将功能分支合并到发布分支。根据流程，我们应该将我们的特性分支合并到dev分支，然后我们可以从dev创建/更新发布分支

长话短说，我需要在部署之前更新开发和发布分支，或者类似的事情。这似乎没有道理

---

那么，在git流上管理这种情况的最佳方法是什么。

答案很简单：

• 团队A不希望使用要素分支→ 他们希望使用不同于Git流的分支和合并模型
• 由于团队A，团队B希望将功能分支直接合并到发布分支→ 他们希望使用不同于Git流的分支和合并模型

结论：不要使用Git流，只使用Git。

我是这么说的，假设每个人都受过使用普通Git的培训，而不仅仅是像Git Flow这样的抽象层。事实上，Git Flow不是一个产品，而是一个分支和合并模型，正如我前面所说的。具有相同名称的Git插件或Git流模型的多个IDE集成只是语法上的糖。如果你想偏离，不要使用它

---

---

技术上有些不相关，只是作为一个经验丰富的人（大约15年）大声思考敏捷教练：它说的是关于两个团队的团队文化和协作，这两个团队为同一个产品做出贡献，并致力于同一个存储库，他们在SCM和发布周期方面找不到共同的策略。

我知道你是对的，但是有20个开发人员，如果没有特定的策略，很难管理他们的输出同意，这就是为什么我建议人们通过流程和工具进行互动。（听起来很熟悉？）Git不难使用，它为您提供了所有特性和自由度，以实现您的团队同意的任何（混合）流。如果GitFlow显然不是两个团队都想使用的，那么不要将自己锁定在GitFlow中。不要把方形的钉子塞进圆孔里。您的流和必要的命令可以记录在开发人员wiki或Git repo内部的标记文件中。为什么要使用Git流？你想解决的问题是什么？