在git-flow中，develop分支是否无用？

Question

每当我寻找在团队中正确使用GIT的方法时，总是被引导到git-flow。

一开始我们把这个方案看作是我们的圣经：

时间过去了，我们终于发现将 master 作为稳定分支并打上标签的做法浪费时间。

为什么要给你的稳定版本打上标签，然后再把相同的版本PUSH到master呢？标签已经存在，你随时可以返回到这个提交版本。为什么还要费心保留这个只包含标签的分支呢？

这里是我们使用的流程，它非常顺畅：

• Master: 实际上是我们的开发分支

• Release: 我们创建一个发布分支来进行最后的发布测试，如果需要添加修复。

• Feature: 我们从Master上创建一个特性分支，然后将其推送到主分支。

实际上，这和git-flow是相同的，只是没有包含稳定分支的分支。

这样做的另一个好处是，master 是 develop 分支。因此，当新团队成员加入项目时，他可以通过克隆项目并使用其master来更新实际的开发。

在图中：

我的问题是，为什么要使用原始的git-flow五个分支，如果您可以只使用四个分支来实现相同的结果？

- Christophe Chenel

---

你可能会对CPython Git工作流程感兴趣。他们不使用develop分支进行开发，而是使用master分支，并且使用支持分支来长期维护多个版本的并行开发。 - Géry Ogam

Answer 1

在我看来，你的工作流存在一个很大的问题：过度使用develop/master分支。

你基本上认为没有必要区分master和develop，因为在develop上保留标签就足够了。乍一看似乎合理，但你修改的图像掩盖了分支的需求：即热修复。

假设你有一个稳定版本的代码，并且已经完成了发布阶段。现在你认为一切都准备好了，在master/develop上创建了一个标签。过了一段时间，客户告诉你有一个bug，而你还没有准备好进行新的发布。你会怎么做？

你唯一的选择是从master/develop分支创建分支。因此，功能、发布和热修复都将从master分支中出现。这种方法的另一个缺点是，一旦在热修复分支上解决了一个bug，你将把它合并到develop/master分支中，但你不能在那个提交上放置一个标签，因为develop/master分支可能同时移动了，并且会有更多（未经测试的）功能，客户不应该拥有。我认为这太多了，提交历史在某些时候会很难理解。但是，正如我在开始时所说，这是可以商榷的。

你的工作流似乎混合了git-flow和基于主干（或主分支）的开发，但大多数情况下都带来了不利影响。

- Marco Luzzara

---

我认为这个答案指出了该问题提出的流程中最大的问题：通过将开发和主分支合并，无法部署先前发布和打标记的修订版本的热修复，而不包括未发布的开发内容。 - Kevin Kruse

针对我的热修复，如果我检出最后一个标记（即我发送给客户的版本），然后分支一个带有热修复的版本。在此分支中修复问题并打上标记，发布并向主分支（即我的活动开发分支）发送拉取请求。这样做似乎可以避免一些“缺点”，但也可能存在一些遗漏点。 - Christophe Chenel

如果我理解正确，问题仍然存在：即使有拉取请求，develop/master 也可能无法准备好使用您的错误修复创建稳定版本，特别是因为您必须在最短时间内提交错误修复。实际上，如果您认为您正在创建工作流程中的瓶颈，那么这是一个更糟糕的选择。虽然使用 git-flow 您可以拥有 develop 团队和 master 团队，但现在它们都被需要集成您的错误修复所阻塞。 - Marco Luzzara

在您的示例中，如果您需要创建第二个热修复，会发生什么情况？它将需要包括来自第一个热修复的更改以及新的热修复，但不包括master / develop 中的其他内容。当第一个热修补程序通过PR合并回来时，它会在开发/主线版本的 HEAD 处进行合并。因此，您无法从该第一个热修补程序合并点创建第二个热修补程序。 - John Camerin

热修补程序可以从标签分支，由于它们最终成为标签本身，因此第二个或第三个热修补程序的过程完全相同。如所述的过程有效。 - whiskeysierra

Answer 2

结果并不相同：在普通的git-flow中，master始终是稳定的 - 这是你的交付物，外部人员可以依赖它。在gitflow术语中，你的 master 是 develop 和 master 的混合体。合并了一个大功能后，结果是否真正稳定并且可以发布或者需要一些更多的错误修复，这是未知的。

话虽如此：Git工作流不是上帝所赋予的。Git-flow受到了很多批评。如果你的团队和依赖你代码的团队都满意，那就采用最小化开销的工作流吧。

最后注意：

这是我们使用的Git-Flow，运行良好。

请不要将你的工作流称为"git-flow"。选择一个明显不同的名称。稀释一个好的搜索术语对任何人都没有好处。

- A.H.

---

我会更新我的问题，避免使用Git-flow，因为它不是一个git flow。再次感谢您的回答！ - Christophe Chenel

使用@ChristopheChenel的方法，"始终稳定"的代码就是发布分支的末尾。 - Jonathan.

Answer 3

一年后，

我终于明白了在 Git Flow 中为什么需要两个分支的必要性。

你需要使用 Git-flow 的唯一原因是当你有一个 CI/CD 并通过任何提交到主分支自动部署到生产环境时。

去年我提出这个问题时，我们没有任何自动部署到生产环境。所以我们可以认为我们使用的方法没有 Develop/Master 是 可以的，并且它节省了我们一些时间，因为我们不必管理多一个分支。

由于我们使用了管道系统（在将任何提交推送到主分支后发布到生产环境），这就给了这个分支一个目的！是的，主分支包含已标记的版本，但自动部署到生产环境的脚本也附加在其中！

- Christophe Chenel

---

合并到主分支是由人类完成的，对吧？那同样的人类是否可以直接在发布分支上启动部署流程呢？ - Jonathan.

你的流水线可以基于标签而非分支开始部署。你原来的工作流程很好，没有问题。Git flow 中的主分支是无用的。 - whiskeysierra

管道还可以创建多个手动作业，因此每次可以根据团队喜欢的任何标准选择部署环境。在只有一个可能的环境的情况下，作业可以是自动的，而不是手动的（例如，标签触发的管道自动部署到暂存和/或生产环境）。 - Kevin Tindall