Git Flow

定义

Git Flow是一种围绕Git设计的分支管理模型，它规定团队在代码库中开设哪些分支、每种分支承担什么职责，以及分支之间如何合并^[1]。该模型把代码划分为始终可上线的生产代码与仍在集成中的开发代码两大部分，再借助若干临时分支在两者之间流转^[2]。

与只保留一条主干的做法相比，Git Flow把功能开发、发布准备和线上紧急修复分别放在不同类型的分支上，使各级环境的变更来源更容易追溯和控制。该模型在发布节奏可预期、需要把一批功能打包成一次发布的团队中使用较多^[3]。

原理

Git Flow的分支分为长期分支与辅助分支两类。长期分支有两条：main（早期称master）保存随时可部署到生产环境的代码，每次发布在此分支上打标签；develop则作为功能集成的中枢，汇集各个已完成的功能，并作为下一次发布的基础^[1]。辅助分支为临时分支，任务完成后即删除，包括feature、release和hotfix三种^[2]。

典型流转过程是：开发者从develop切出feature分支编写新功能，完成后合并回develop；当一批功能齐备，从develop切出release分支进行测试与收尾，通过验证后分别并入main与develop；若生产环境出现严重问题，则从main切出hotfix分支修复，修好后同样合并回main与develop，避免该缺陷在后续版本中重现^[1]。

分支之间的合并关系可以用下面的图表示：

gitGraph

commit

branch develop

checkout develop

commit

branch feature/xxx

checkout feature/xxx

commit

checkout develop

merge feature/xxx

branch release/1.0

checkout release/1.0

commit

checkout main

merge release/1.0

checkout develop

merge release/1.0

checkout main

branch hotfix/1.0.1

commit

checkout main

merge hotfix/1.0.1

checkout develop

merge hotfix/1.0.1

发展历程

2010 年 1 月，Vincent Driessen 在其个人博客发表文章《一个成功的 Git 分支模型》，系统描述了这一套分支与发布流程，此后该文章成为搜索 Git 工作流时最常被引用的文献之一^[2]。同年，Driessen 又编写了一组名为 git-flow 的 Git 扩展脚本，把模型中的高层操作封装成命令，运行时可以通过 git config 配置 main、develop 的名称以及各类分支的前缀。

此后该扩展出现了多个实现版本。原作者曾于 2007 年开始用 Python 重写，但未完成；2012 年 Hartmut Goebel 接手完成并独立发布，形成了另一套可供选择的实现^[4]。随着持续交付与 DevOps 实践的普及，Git Flow 被指出与频繁小批量发布的节奏不够契合，GitHub Flow、主干开发等更轻量的模型随之被更多团队采用^[5]。

AWS 在其规范性指引中把 Gitflow 与 GitHub Flow、Trunk 并列为三种常见分支策略，并指出 Gitflow 是三者的复杂程度最高者^[6]。该指引 2024 年 2 月的文档说明中，仍将 Gitflow 作为标准分支模型之一推荐给需要对齐开发流程的组织^[6]。

应用

Git Flow主要应用于有明确版本号和计划发布周期的软件项目，尤其是需要把若干功能合并为一次发布、并对不同环境分别设置部署门槛的团队。在云上实施时，常见的做法是由 feature 分支合并到 develop 触发持续集成流水线，部署到开发环境；再从 develop 切出 release 分支，经测试、预发布环境的分级审批后发布到生产环境^[7]。

配套工具方面，git-flow 扩展通过 git flow feature start、git flow release finish 等命令完成分支创建与合并，减少手工操作出错的可能；部分图形化客户端也内置了对该模型的配置与命令支持^[8]。使用时通常需要先执行一次配置命令，确定主分支、开发分支的名称与各类分支前缀，配置结果保存在代码库的配置文件中^[8]。

局限

Git Flow引入了较多分支和合并步骤，对小型项目或已采用持续交付的团队而言负担偏重，管理和合并多个分支可能拖慢开发进度^[9]。在持续交付场景下，要求每次提交都能快速进入生产环境，而 Git Flow 的分层结构会拉长从提交到上线的路径^[5]。

该模型最初对同时维护多个发布版本的支持并不充分，原作者在文章评论中补充了以 support 分支支撑旧版本维护的做法^[10]。在 git-flow 扩展中，support 分支相关功能长期标注为实验性状态，使用它会给代码库带来额外的复杂度^[8]。

落地时的另一处风险是分支冲突：若同时存在多个活跃的 release 分支，各环境中的改动可能相互碰撞，导致某个分支无法继续向生产环境推进^[7]。因此有建议指出，同一时间最好只保留一个 release 分支，并在发布后尽快将改动合并回主分支与开发分支^[7]。

参见

• Git —— Git Flow 所依托的分布式版本控制系统。

• GitHub Flow —— 只保留主干与短期工作分支的轻量级分支模型。

• 持续交付 —— Git Flow 在实践适用性上常被与之对比的工程实践。

• 持续集成 —— 与分支模型配套、决定代码合并频率的工程实践。

• 主干开发 —— 强调在单一主干上频繁集成的分支策略。