Develop分支在gitflow中没有用吗？

Question

每当我在团队中寻找使用git的正确方法时，我们总是会提到git-flow。

我们从一开始就开始将此计划用作圣经。

时间的流逝，我们最终发现将master保留为带有标记的commit的稳定分支是浪费时间。

为什么要标记稳定的提交，然后按PUSH以掌握已经标记的相同版本。标签存在，您可以随时返回此提交。为什么要麻烦我保留此分支仅包含标签？

这是我们使用的Git-Flow，它的工作原理就像一种魅力。

Master：实际上是我们的开发分支Release：我们创建一个release分支来做最后一个发布测试用例，然后在需要时添加修订。功能：我们从Master分支创建功能，然后将拉取请求发送给master。

实际上，它与gitflow相同，没有包含稳定的分支。

这样做的另一个优点是，MASTER是DEVELOP分支。因此，当新的队友进入该项目时，他可以从克隆项目开始，而他的主人已经与实际开发保持同步。

在图像中：

我的问题是，如果您只能用相同的结果管理4个分支，为什么还要使用原始的git-flow和5个分支？

Answer 1

结果是不一样的：在简单的git-flow master中始终保持稳定-这是您团队之外的可交付人员可以依靠的。你master是的混合物develop，并master在gitflow发言。合并重大功能后，无论结果是否真的稳定并准备好发布或需要更多错误修正，都无法下注。

就是说：Git工作流不是上帝赋予的。Git-flow受到了很多批评。如果您的团队和依赖您代码的团队感到满意，那么请以最小的开销进行工作流。

最后说明：

这是我们使用的Git-Flow，它的工作原理就像一种魅力。

请不要将您的工作流程称为“ git-flow”。选择一个明显不同的名称。稀释一个好的搜索词对任何人都没有帮助。

Answer 2

我认为您的工作流程存在一个大问题：过度使用开发/主分支。

您基本上是在说，不需要区分母版和开发，因为将标签保留在开发上就足够了。乍一看似乎很合理，但是您修改过的图像隐藏了分支的需要：修补程序。

假设您有一个稳定的代码版本，并且您已经完成了发布阶段。现在您相信一切就绪，并在master / develop上创建标签。一段时间后，客户使您注意到您有一个错误，并且您尚未准备好发布新版本。你是做什么？

您唯一的选择是从master / develop分支。因此，功能，发行版和修补程序将来自主机。这种方法的另一个缺点是，一旦在修补程序分支上解决了一个错误，您便可以将其合并到develop / master中，但是您不能在该提交上放置标签，因为develop / master分支可能同时移动了，而且它还会有更多的（未测试）客户不应该拥有的功能。我认为这太过分了，在某些时候将很难理解提交历史。但是，正如我刚开始所说的那样，这值得商de。

您的工作流程似乎将git-flow和基于trunk（或master）的开发混合在一起，但大多数情况下都存在缺点。