GitFlow 是我们今天仍在讨论的最古老且最结构化的分支模型之一。

它在 2010 年推出，并因其清晰地将开发、发布、功能和热修复分开而流行起来，这是当时许多团队所需要的。

它定义了一组具有特定用途的分支：

- main 用于生产就绪代码
- develop 作为集成分支
- feature/ 用于新功能
- release/ 用于准备即将发布的版本
- hotfix/ 用于紧急生产修复。

这种工作流程非常适合遵循计划发布、维护多个版本，或具有严格 QA 和合规关卡的团队。

一切都在结构化的路径中移动，长期维护变得更容易管理。

但 GitFlow 也带来了真正的缺点。

它增加了很多复杂性，鼓励使用长期存在的分支，并因每个阶段都需要协调而减缓交付速度。

这就是为什么构建快速迭代产品或进行持续部署的团队通常会避免它。

GitFlow 仍然有价值，但除非你真正需要那种程度的流程和分离，否则它不是今天的首选选项。编程开发 知识分享 每天跟我涨知识