很多开发者用 Git 很久，却始终停留在「所有代码直接提交到 master」的阶段。当项目变大、团队变多，这种做法迟早会出问题。本文系统梳理业界四种主流 Git 分支管理策略，帮你根据团队规模和项目特点做出正确选择。
一、为什么需要分支策略？
没有分支管理的典型混乱场景：
- 多人同时改同一个文件，合并时冲突不断
- 线上出了 bug，但新功能开发到一半，代码混在一起无法单独修复
- 不确定哪些代码已经测试过、哪些还在开发中
- 回滚一个功能，牵连其他正常功能
分支策略的核心目的：让不同状态的代码（开发中、测试中、已发布）在物理上隔离，降低协作冲突的风险。
二、Git Flow：最经典的重型方案
Git Flow 由 Vincent Driessen 于 2010 年提出，是第一种被广泛采用的分支模型。它定义了五种分支类型，覆盖从开发到发布的完整生命周期。
分支结构
| 分支类型 | 命名 | 生命周期 | 用途 |
|---|---|---|---|
| 主分支 | master | 永久 | 生产环境代码，每次提交都是一个可发布版本 |
| 开发分支 | develop | 永久 | 日常开发的集成分支，包含最新的开发成果 |
| 功能分支 | feature/* | 临时 | 从 develop 拉出，开发完成后合回 develop |
| 发布分支 | release/* | 临时 | 从 develop 拉出，只做 bug 修复和版本号更新，最终合入 master 和 develop |
| 热修复分支 | hotfix/* | 临时 | 从 master 拉出，紧急修复线上 bug，同时合入 master 和 develop |
工作流程
- 从
develop创建feature/xxx分支开发新功能 - 功能开发完成，合并回
develop - 准备发布时，从
develop创建release/v1.0 - 在 release 分支上测试、修 bug（不再加新功能）
- 测试通过，合并到
master（打 tag）和develop - 线上紧急 bug？从
master拉hotfix/xxx，修完合回master和develop
适用场景
- 有明确版本发布周期的项目（如桌面软件、移动 App）
- 需要同时维护多个历史版本
- 团队有独立的 QA 测试环节
- 团队规模 ≥ 10 人
局限性
- 分支多、流程重，小团队用起来像「杀鸡用牛刀」
- 长命分支容易积累合并冲突
- 不适合持续部署的 Web 项目
Git Flow 的原作者 Driessen 本人也说过：「如果你在做持续交付的 Web 项目，请使用更简单的工作流，不要硬塞 Git Flow。」
三、GitHub Flow：简洁至上的轻量方案
GitHub Flow 是 GitHub 官方推荐的分支策略，也是目前开源社区最流行的模式。核心理念：master 随时可部署，所有开发都在短命分支上进行。
分支结构
| 分支类型 | 命名 | 用途 |
|---|---|---|
| 主分支 | master | 始终可部署的生产代码 |
| 功能分支 | feature/* / fix/* | 从 master 拉出，完成后通过 PR 合回 |
工作流程
- 从
master创建描述性分支（如feature/add-search） - 在分支上频繁提交，保持改动小而完整
- 开发完成，创建 Pull Request（PR）
- 团队成员 Code Review
- Review 通过，合并到
master - 立即部署到生产环境
- 删除已合并的功能分支
适用场景
- 持续部署的 Web 应用
- 2-8 人的中小团队
- 开源项目（Fork + PR 模式天然契合）
- 个人项目（想保持干净的提交历史）
局限性
- 没有显式的版本管理，不适合需要维护多版本的项目
- 如果缺乏自动化测试，频繁部署可能引入线上问题
四、GitLab Flow：折中方案
GitLab Flow 在 GitHub Flow 的简洁性基础上，增加了环境分支来应对多环境部署的需求。
核心改进
GitHub Flow 只有一个 master 分支，GitLab Flow 在此基础上增加了：
staging分支 — 对应测试环境production分支 — 对应生产环境
开发流程：功能分支 → 合入 master → 挑选（cherry-pick）到 staging 测试 → 测试通过后挑选到 production 发布。
适用场景
- 需要测试环境与生产环境隔离的团队
- 喜欢 GitHub Flow 的简洁，但需要更多环境控制
五、Trunk-Based Development：主干开发
主干开发（Trunk-Based Development, TBD）是最激进的策略：所有人直接在 main/master 上提交，几乎不使用分支。
核心理念
- 所有开发者频繁向主干提交（每天至少一次）
- 提交前必须通过完整的自动化测试
- 需要发布时，从主干拉一个 release 分支（只读，只做 bug 修复）
- 未完成的功能用「功能开关（Feature Flag）」隐藏，而不是用分支隔离
适用场景
- Google、Meta 等超大规模公司的内部实践
- 拥有强大 CI/CD 和自动化测试基础设施的团队
- 追求极致迭代速度的场景
局限性
- 对自动化测试要求极高，没有测试覆盖就等于裸奔
- 需要功能开关机制配合
- 不适合测试能力不成熟的团队
六、四种策略对比速查
| 维度 | Git Flow | GitHub Flow | GitLab Flow | 主干开发 |
|---|---|---|---|---|
| 分支数量 | 5 种 | 2 种 | 3-4 种 | 1 种（+ release） |
| 复杂度 | 高 | 低 | 中 | 低（但 CI 要求高） |
| 适合团队 | ≥ 10 人 | 2-8 人 | 5-15 人 | 成熟团队 |
| 发布方式 | 定期发版 | 持续部署 | 环境递进 | 持续部署 |
| 多版本支持 | 好 | 差 | 中 | 差 |
| 典型用户 | 传统软件公司 | GitHub / 开源社区 | GitLab 用户 | Google / Meta |
七、个人项目和小团队的实用建议
对于 1-3 人的小团队或个人项目，推荐三层分支策略：master（生产）→ test（测试）→ feature（开发）。相比纯 GitHub Flow 多了一层测试保障，又不像 Git Flow 那么重。
三个长期分支
| 分支 | 用途 | 说明 |
|---|---|---|
master | 生产环境 | 始终可部署的稳定代码，对应线上网站 |
test | 测试环境 | 功能验证通过后才合入 master，防止未测试的代码污染生产 |
feature/* | 开发分支 | 从 test 拉出，完成后合回 test，短命分支用完即删 |
分支流转方向
feature/* → test → master
（开发） （测试） （生产）禁止反向合并（master → test → feature），也禁止 feature 直接跳过 test 合入 master。
判断规则
| 改动类型 | 操作方式 |
|---|---|
| 小改动（≤ 3 个文件） | 直接提交到 master |
| 纯内容变更（博客文章、文案） | 直接提交到 master |
| Bug 修复（几行代码） | 直接提交到 master |
| 配置微调（缓存戳、文档） | 直接提交到 master |
| 新功能（≥ 5 个文件） | feature → test → master |
| 代码重构 | feature → test → master |
| 多个独立功能并行 | 各开 feature 分支，分别走 test → master |
分支命名规范
feature/<简短描述> # 新功能
fix/<问题描述> # Bug 修复示例：feature/blog-search、fix/navbar-mobile-layout
完整操作流程
# === 第一步：创建 feature 分支（从 test 拉出）===
git checkout test
git pull origin test
git checkout -b feature/blog-search
# === 第二步：在 feature 分支上开发并提交 ===
# ... 编码 ...
git add .
git commit -m "feat: 添加博客搜索功能"
# === 第三步：开发完成，合入 test 测试 ===
git checkout test
git pull origin test
git merge feature/blog-search
# 解决冲突（如有）
git push origin test
# === 第四步：测试通过，合入 master 发布 ===
git checkout master
git pull origin master
git merge test
# 解决冲突（如有）
git push origin master
# === 第五步：清理已合并的 feature 分支 ===
git branch -d feature/blog-searchtest 分支的价值
有人可能会问：一个人开发，为什么还需要 test 分支？
- 防止「改 A 坏 B」：新功能涉及多文件改动时，在 test 分支上完整验证，确认没有副作用再上生产
- 保留回滚能力：master 始终是稳定的，test 出问题直接丢弃重来，不影响线上
- 养成专业习惯：现在是一个人，未来团队扩大时，test 分支是必需的，提前养成习惯零成本
- 配合部署流程：test 分支可以部署到测试服务器（如本地预览），master 部署到线上，互不干扰
八、Commit Message 规范
无论用哪种分支策略，规范的 commit message 都是必要的。推荐使用 Conventional Commits 格式：
<type>(<scope>): <subject>| type | 含义 | 示例 |
|---|---|---|
feat | 新功能 | feat: 资源导航页添加搜索框 |
fix | Bug 修复 | fix: 修复移动端导航栏布局错位 |
docs | 文档变更 | docs: 更新 CLAUDE.md 缓存规则 |
style | 样式调整（不影响逻辑） | style: 统一缩进为 2 空格 |
refactor | 重构（不新增功能也不修 bug） | refactor: 提取搜索逻辑为独立模块 |
chore | 构建/工具变更 | chore: 清理临时文件 |
九、小结
没有「最好」的分支策略，只有「最适合」的。选择依据三个维度：
- 团队规模：1 人 → 直接 master 或简化 GitHub Flow；2-8 人 → GitHub Flow；10+ 人 → Git Flow
- 发布方式：持续部署 → GitHub Flow / 主干开发；定期发版 → Git Flow
- 自动化程度：强 CI/CD → 主干开发；有 QA 环节 → Git Flow
对于大多数个人开发者和小团队，推荐三层分支策略（master → test → feature）：小改动直接提交 master，大功能走 feature → test → master 的完整流程。test 分支提供了测试与生产的隔离，既不过于复杂，又能有效防止未验证的代码污染线上环境。
