Git 分支策略：Git Flow 与 GitHub Flow

在多人协作开发中，如何管理代码版本、协调功能开发与发布节奏，是团队效率的关键。Git 提供了强大的分支能力，而 Git Flow 和 GitHub Flow 是两种主流的分支使用策略。它们目标不同、适用场景各异。本文将手把手教你理解并选择适合你项目的策略。

什么是 Git Flow？

Git Flow 是由 Vincent Driessen 在 2010 年提出的一种严格、结构化的分支模型，适用于有明确版本发布周期的项目（如桌面软件、企业级应用）。它定义了五种核心分支类型，每种有固定用途和生命周期。

Git Flow 的五种分支

如何使用 Git Flow？（手动操作步骤）

1. 初始化项目主干
   创建空仓库后，创建 main 和 develop 分支：

   git checkout -b main
   git commit --allow-empty -m "Initial commit"
   git push origin main
   git checkout -b develop
   git push origin develop

2. 开始开发新功能
   从 develop 切出一个以 feature/ 开头的分支：

   git checkout develop
   git checkout -b feature/user-login

   在该分支上编码、提交。完成后，合并回 develop：

   git checkout develop
   git merge --no-ff feature/user-login
   git branch -d feature/user-login

3. 准备发布版本
   当 develop 足够稳定时，切出 release/ 分支（例如 release/v1.0）：

   git checkout develop
   git checkout -b release/v1.0

   在此分支上只允许修复 bug，不允许新增功能。测试通过后：

   • 合并到 main，并打上版本标签（如 v1.0）
   • 合并回 develop（确保修复也进入开发线）
   • 删除 release/v1.0 分支

4. 紧急修复线上问题
   从 main 切出 hotfix/ 分支（如 hotfix/login-bug）：

   git checkout main
   git checkout -b hotfix/login-bug

   修复后：

   • 合并到 main，打补丁标签（如 v1.0.1）
   • 合并到 develop
   • 删除 hotfix/ 分支

⚠️ 注意：Git Flow 流程较重，适合有专职测试、发布团队的项目。小团队或快速迭代项目可能觉得繁琐。

什么是 GitHub Flow？

GitHub Flow 是一种极简、轻量的分支策略，由 GitHub 团队提出，专为持续交付（Continuous Delivery）设计。它假设每次合并到主干的代码都应能立即部署上线。

GitHub Flow 的核心规则

• 只有一个长期分支：main（或 master），且始终处于可部署状态。
• 所有新工作都在短期功能分支上进行，分支名无强制前缀（但建议语义化，如 add-search）。
• 功能完成后，必须通过 Pull Request（PR）。
• PR 被批准并合并后，立即部署到生产环境。

如何使用 GitHub Flow？（实操步骤）

1. 确保 main 是干净的
   拉取最新代码：

   git checkout main
   git pull origin main

2. 创建功能分支
   基于 main 创建新分支：

   git checkout -b fix-header-style

3. 开发并推送
   编码、提交后，推送到远程（即使未完成）：

   git push origin fix-header-style

4. 发起 Pull Request
   在 GitHub 界面，点击 “Compare & pull request”，填写描述，指定 reviewer。

5. 代码审查与合并
   Reviewer 检查代码、运行自动化测试。通过后，点击 “Merge pull request”。
   合并后，立即触发部署流程（通常通过 CI/CD 工具自动完成）。

6. 清理本地分支（可选）
   删除已合并的本地分支：

   git checkout main
   git pull origin main
   git branch -d fix-header-style

✅ 优势：流程简单、反馈快、适合 Web 应用或 SaaS 产品。
❌ 风险：要求完善的自动化测试和一键部署能力，否则“随时可上线”会带来隐患。

如何选择？关键对比表

以下表格帮你快速决策：

实际建议

• 如果你的项目没有专职运维、缺乏自动化测试，但又有明确版本计划（如季度发布），选择 Git Flow，它提供了清晰的缓冲区（release/ 分支）。
• 如果你的团队每天多次部署、有完善的 CI/CD 流水线（如自动跑测试、自动部署到 staging），选择 GitHub Flow，避免流程内耗。
• 不要强行套用：有些团队混合使用——日常用 GitHub Flow，大版本前临时切到类似 Git Flow 的 release/ 分支做封版测试。

切换策略很简单：分支只是指针，只要团队达成共识，下次功能开发时改用新规则即可。重点不是工具，而是让分支模型服务于你的交付节奏。