看起来下面实现的 Git-Flow 很受欢迎。
现在想象一下 master 分支消失了:feature 分支是从 develop 创建的，然后 merge 回 develop...就像旧的 Git-Flow 一样。
当您需要发布代码时，您只需从 develop 创建发布分支，然后 merge 回 develop only，当然，您不要忘记创建标签。
因此与标准 Git-Flow 不同，没有从发布分支 merge 到 master 并且标签是在开发时创建的。
如果您决定创建一个修补程序，您可以从 develop 上的标签创建您的修补程序分支。 从 master 创建修补程序可能不是一个好主意:如果实际产品版本是 0.1 但另一个版本 0.2 已经构建并发送到用户接受环境，那么 master 将等于版本 0.2 而不是实际产品版本 (0.1)
它认为这是与 Git-Flow 的常见混淆，master 是生产就绪代码，不一定是生产代码。
我的问题是:为什么我们需要维护主分支？什么是附加值？
谢谢
最佳答案
为什么要维护master分支？附加值是多少？
让我重新使用已链接的文章(感谢 VLAZ!):
关于 --no-ff 是否有助于提高可读性的讨论正在进行中。
使用此选项会导致 develop 分支仅包含功能的 merge 提交，因此成为集成到产品中的所有功能的有序列表。
您的 master 分支不是别的:所有已发布版本的有序列表。
你一定需要它吗？绝对不是。
它对某些项目/团队有帮助吗？当然!
您的团队可以根据您的需要调整此框架。
也许是更轻量级的东西——比如 Github flow - 对您来说是更好的方法。
这两种方式都是完全可以接受的，而且 - 像往常一样 - 没有一种放之四海而皆准的方式。 ;)
关于Git 流程 - 为什么使用/维护 master 分支？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61526122/