Git Flow（也叫Gitflow）是一套结构化的Git分支管理工作流，最早由Vincent Driessen提出推广，核心为不同分支赋予明确角色，规范了代码开发、发布和修复的完整流程，非常适合有固定发布周期的大型项目使用。
核心分支体系
Git Flow 将分支分为两类：两个永久主分支 + 多个临时辅助分支，分工清晰互不干扰：
表格
分支类型 作用说明 分支规则
master（主分支） 永久存在，始终保存生产环境可发布的稳定代码 禁止直接提交修改，所有更新都来自其他分支合并，每次发布需要打上对应版本标签
develop（开发分支） 永久存在，是功能开发的集成分支，始终包含下一个待发布版本的全部功能 接收功能分支、热修复分支的合并，作为日常开发的主干
feature/xxx（功能分支） 临时分支，用于开发新功能 从develop分支分出，开发完成后合并回develop分支，合并后可删除，禁止直接与master交互
release/xxx（发布分支） 临时分支，用于版本发布前的准备 积累足够功能后，从develop分出，仅修复发布前发现的Bug，不再新增功能；测试完成后同时合并到master和develop，完成发布后可删除
hotfix/xxx（热修复分支） 临时分支，用于快速修复线上生产环境的紧急Bug 唯一直接从master分出的辅助分支，修复完成后同时合并回master和develop，并在master打新版本标签，修复完成后可删除
完整工作流程
项目初始阶段，从master分出develop作为日常开发主干；
开发新功能：从develop切出feature分支，开发完成后合并回develop；
准备发布：从develop切出release分支，进行最终测试和Bug修复；
正式上线：将release分支合并到master打版本标签，同时同步更新develop；
紧急修复线上问题：从master切出hotfix分支，修复完成后合并回master和develop，重新打标签。
适用场景与优缺点
Git Flow结构严谨，角色清晰，能让团队多人协作开发变得更有序，但分支操作更复杂，更适合：
有固定发布周期的传统项目：例如大型客户端软件、需要多版本维护的项目
规模较大、协作人数多的团队：流程规范能降低沟通协作成本
它不适合持续交付、小版本快速迭代的互联网项目，这类场景更推荐轻量的GitHub Flow。