Git Flow 工作流完全指南
概述
Git Flow 是一套基于 Git 的分支管理模型，由 Vincent Driessen 在 2010 年提出并被广泛采用。它通过为不同类型的开发任务分配固定用途的分支，使团队协作更加有序，特别适合有固定发布周期的大型项目。本文详细介绍 Git Flow 的完整工作流程、各分支的职责以及在实际团队中的最佳实践。
基础语法
Git Flow 的核心是将开发活动拆分到不同类型的分支中，每种分支都有明确的职责范围：
- main/master：生产环境分支，仅存放经过测试的正式发布版本，任何时候都应保持可发布状态。
- develop：开发主分支，汇集了所有已完成的特性（feature）分支，是下一版本开发的基础。
- feature/*：特性分支，从 develop 分支创建，用于开发新功能，完成后合并回 develop。
- release/*：发布分支，从 develop 创建，用于发布前的最后调整和 Bug 修复，只能合并到 main 和 develop。
- hotfix/*：热修复分支，从 main 创建，用于紧急修复生产环境的 Bug，完成后同时合并到 main 和 develop。
Git Flow 的核心命令遵循固定格式：feature 分支从 develop 创建，完成后合并回 develop；release 分支从 develop 拉出，准备发布；hotfix 分支从 main 拉出，修复完成后双向合并。
完整代码示例+注释
以下示例演示完整的 Git Flow 开发流程，从开发新功能到正式发布：
# === 1. 开始一个新特性 ===
从 develop 创建特性分支
git checkout develop
git pull origin develop
git checkout -b feature/user-authentication
=== 2. 开发完成后，合并到 develop ===
git checkout develop
git pull origin develop
使用 --no-ff 保留分支合并历史，便于追溯
git merge --no-ff feature/user-authentication
git push origin develop
删除已合并的特性分支
git branch -d feature/user-authentication
=== 3. 准备发布版本 ===
从 develop 创建发布分支
git checkout develop
git pull origin develop
git checkout -b release/v1.2.0
在发布分支上修改版本号、更新日志等
修复发布分支上的小问题（不要引入新特性）
git commit -m "fix: update version to 1.2.0"
=== 4. 完成发布 ===
合并到 main
git checkout main
git pull origin main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin main --tags
合并回 develop
git checkout develop
git merge --no-ff release/v1.2.0
git push origin develop
删除发布分支
git branch -d release/v1.2.0
=== 5. 紧急热修复 ===
从 main 创建热修复分支
git checkout main
git pull origin main
git checkout -b hotfix/critical-security-fix
修复完成后直接合并到 main 和 develop
git checkout main
git merge --no-ff hotfix/critical-security-fix
git tag -a v1.2.1 -m "Hotfix version 1.2.1"
git push origin main --tags
git checkout develop
git merge --no-ff hotfix/critical-security-fix
git push origin develop
git branch -d hotfix/critical-security-fix
运行效果
使用 Git Flow 后，仓库的分支结构会非常清晰。在 git flow init 初始化后，每次开发新功能都在独立的 feature 分支上进行，不会污染主开发线。当一个版本的所有特性都完成并合并到 develop 后，从 develop 拉出 release 分支进入发布准备阶段，此时 develop 可以继续接收下一个版本的特性开发。
在代码审查平台（如 GitLab/GitHub）上，每个合并请求（MR/PR）都会清楚地显示该分支的目的（新增特性、Bug修复还是热修复），审核者可以更有针对性地提出意见。最终的发布版本通过 tag 标记，配合 CI/CD 流水线可以实现自动化构建和部署。
常见问题
Q1：特性分支合并时出现冲突怎么办
当 merge 时出现冲突，Git 会暂停并标记冲突文件。首先打开冲突文件，Git 用 <<<<<<< 和 >>>>>>> 标记了冲突区域，手动保留或合并需要的代码后删除标记符号。然后 git add 标记为已解决，再执行 git commit 完成合并。如果冲突复杂，建议与相关开发者沟通后再处理。
Q2：发布分支和特性分支能否同时开发
完全可以。release/v1.2.0 在做发布准备的同时，develop 分支上的其他开发者可以继续在 feature/* 分支上开发下一个版本的特性。两者互不干扰，只是在合并回 develop 时注意不要把未完成的特性带进去。
Q3：hotfix 分支合并时 develop 已经领先很多怎么办
热修复通常涉及冲突较少的安全补丁，合并时可能需要手动解决少量冲突。冲突解决后分别提交到 main 和 develop 即可。由于 develop 已经包含很多新代码，hotfix 只携带必要的修复，冲突范围可控。如果冲突严重，考虑在 develop 上重新应用修复。
Q4：Git Flow 流程太重，小团队是否值得使用
对于 3 人以下的小团队或短期项目，Git Flow 的全部分支类型可能过于复杂。可以简化使用：只用 main + feature 分支，甚至直接采用 GitHub Flow（始终从 main 创建特性分支，审核后合并回 main）。流程是为团队服务的，适度裁剪是合理的。
延伸阅读
- Vincent Driessen 原博文：https://nvie.com/posts/a-successful-git-branching-model/ — Git Flow 模型的设计初衷与详细说明。
- git-flow 工具：提供 git flow 命令简化操作，不必记忆每条分支合并命令，适合不习惯纯命令行的开发者。
- GitLab Flow：在 Git Flow 基础上简化了发布分支，强调上游优先（upstream first）的持续发布理念，适合 SaaS 类产品。