Git flow - 为什么要使用/维护主分支？

Question

看起来下面实现的 Git-Flow 很受欢迎。

现在想象一下，主分支已经消失：功能分支是从 develop 创建并合并回 develop……就像早期的 Git-Flow。

当你需要发布你的代码时，只需从 develop 分支创建发布分支，然后将其合并回 develop，当然，不要忘记创建标签。

因此，与标准的 Git-Flow 不同，没有从发布分支到主分支的合并，标签是在 develop 分支上创建的。

如果你决定创建热修复，可以直接从 develop 上的标签创建你的热修复分支。从 master 上创建热修复可能不是一个好主意：如果实际生产版本为 0.1，但另一个版本 0.2 已经构建并发送到用户验收环境，那么 master 将等于版本 0.2，而不是实际生产版本（0.1）。

我认为这是 Git-Flow 的一个常见困惑，master 是生产就绪的代码，但不一定是“生产代码”。

我的问题是：为什么我们需要维护 master 分支？它有什么附加值吗？

谢谢

- Thomas K

---

老实说，我不知道。我很想看到一个解释。我最好的猜测是，对于不太熟悉Git的人来说，有一个分支会让他们感到“更安全”。但是，Git对分支的理解是不同的 - 任何可寻址的提交都是分支。添加一个命名标签，你就有了一个分支。因此，如果你标记你的发布版本，你就自动拥有了“发布分支”。如果你只标记开发版本的稳定版本，那么主分支确实是不必要的。 - VLAZ

你可能会对这篇文章感兴趣。有人实现了这个模型——放弃了master分支，只使用其他分支。他称之为"OneFlow"。（更准确地说，是放弃了master分支并将develop重命名为master。但出于简单起见，我倾向于保留develop分支） - VLAZ

谢谢，非常有趣的阅读。 - Thomas K

Answer 1

为什么我们需要维护主分支？它有什么附加价值？

让我们重复使用已经链接的文章（感谢VLAZ！）： 关于--no-ff是否有助于可读性，正在进行讨论。 使用此选项会导致develop分支仅由功能合并提交组成，因此是所有实现并集成到产品中的功能的有序列表。

您的master分支也是如此：所有发布版本的有序列表。
您一定需要它吗？绝对不需要。
对于某些项目/团队来说，它可能仍然有帮助。当然！

您的团队可以根据需要调整此框架。
也许更轻量级的方法 - 如Github flow - 对您来说是更好的方法。

两种方法都是完全可以接受的，而且像往常一样，并没有一种解决所有问题的方法。 ;)

- Dominic Frei