Develop分支在gitflow中没有用吗？

Question

每一个我在寻找在团队中使用git的正确方法的地方，我们总是指git-flow。

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

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

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

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

Master：实际上是我们的开发部门 发行版：我们创建发行版分支来进行最后的发行测试用例，然后根据需要添加修复程序。 功能：我们从Master分支创建功能，然后将拉取请求发送给master。

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

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

在图像中：

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

Answer 1

结果不一样：在简单的git-flow master中始终保持稳定-这是您团队之外的可交付人员可以依靠的。您的master是develop和master的混音，用gitflow表示。合并重大功能后，无论结果是否真的稳定且可以交付使用，还是需要更多错误修正，都无法进行。

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

最后的提示：

  

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

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

Answer 2

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

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

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

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

您的工作流程似乎混合了基于git-flow和主干（或主版本）的开发，但是大多数都从它们身上取了缺点。

Answer 3

一年后，

我终于了解了git流中两个分开的分支的必要性。

您需要 Git-flow 的唯一原因是当您拥有一个CI / CD，并且可以通过对master分支的任何提交自动部署到生产环境。

去年，当我问这个问题时，我们没有任何自动部署到生产环境中。因此，我们可能认为在没有Develop / Master的情况下使用的方法确定，并且为我们节省了一些时间，因为我们无需再管理一个分支。

由于我们使用管道系统（在提交至Master分支后释放到生产中），因此该分支有其用途！是的，master分支包含标记的版本，但是还附带了用于自动部署到生产环境的脚本！