第14章：分支策略 —— 从混乱到有序

第14章：分支策略 —— 从混乱到有序

想象一下这个场景：你是一个五人团队的负责人，每个人都在main分支上开发。张三在改登录功能，李四在加支付模块，王五在修Bug，赵六在重构代码。大家每天推送代码，冲突不断，Bug频出，上线时谁也不知道代码能不能跑。终于有一天，main分支崩溃了，你们花了一周时间才恢复。这就是没有分支策略的噩梦！

分支策略就像是交通规则，没有它，代码库会乱成一锅粥。这一章，我们来学习业界成熟的分支策略，让你的团队协作井井有条。

14.1 分支策略概述：为什么需要规范？

什么是分支策略？

分支策略（Branching Strategy）是一套规范，定义了：

• 有哪些分支？
• 每个分支的用途是什么？
• 分支之间如何合并？
• 什么时候创建分支？什么时候删除？

简单来说，就是给代码的分支管理制定"交通规则"。

为什么需要分支策略？

1. 隔离风险——别把实验品推到生产环境

开发中的代码就像实验室里的化学品，不稳定、可能爆炸。分支策略确保实验性的代码不会直接影响生产环境。

❌ 没有分支策略：
main分支：实验代码 + 半成品 + Bug修复 + 稳定代码 = 💥

✅ 有分支策略：
main：稳定代码（生产环境）
develop：开发代码（测试环境）
feature-xxx：实验代码（隔离开发）

2. 并行开发——多人协作不打架

五个人同时开发五个功能，没有分支的话，代码会乱成一锅粥。分支让每个人有自己的工作空间，互不干扰。

张三：feature-login ──▶ develop
李四：feature-payment ──▶ develop
王五：bugfix-crash ──▶ develop

最后：develop ──▶ main

3. 版本管理——知道每个版本是什么

清晰的版本号，知道每个版本包含什么功能，方便回滚和问题追踪。

v1.0.0：基础功能
v1.1.0：新增支付功能
v1.1.1：修复支付Bug
v1.2.0：新增搜索功能

4. 代码审查——在合并前把关

通过Pull Request在合并前审查代码，保证质量，分享知识。

5. 快速修复——生产环境出Bug怎么办？

生产环境出Bug了？从稳定分支快速创建hotfix分支，修复后合并，不影响正在开发的功能。

main（生产环境发现Bug）
  ↓
hotfix-1.0.1（紧急修复）
  ↓
main（修复后发布v1.0.1）
develop（继续开发，不受影响）

没有策略的混乱现场

让我们看看没有分支策略会发生什么：

第1天：
main分支：A---B---C（稳定）

第2天：
张三推送登录功能：A---B---C---D（测试通过）
李四推送支付功能：A---B---C---E（还没测试）
main分支：A---B---C---D---E（混合了）

第3天：
王五推送Bug修复：A---B---C---D---E---F
赵六推送重构：A---B---C---D---E---F---G（有Bug）
main分支：A---B---C---D---E---F---G（💥崩溃！）

结果：
- 不知道哪个提交引入了Bug
- 无法单独回滚某个功能
- 上线风险极高
- 团队互相指责

有策略的清晰流程

再看看有分支策略的情况：

main（稳定生产代码）
  ↑
develop（开发主分支）
  ├── feature-login（张三开发）
  │     └── 完成后合并到develop
  ├── feature-payment（李四开发）
  │     └── 测试通过后合并到develop
  └── bugfix-crash（王五修复）
        └── 紧急合并到develop

develop测试通过后 ──▶ main（发布新版本）

结果：
- 每个功能独立开发
- 可以单独测试和回滚
- 上线风险可控
- 团队协作顺畅

主流分支策略概览

如何选择？

选择分支策略要考虑：

1. 团队规模

   • 小团队（1-5人）：GitHub Flow或Trunk-Based
   • 中团队（5-20人）：GitLab Flow
   • 大团队（20+人）：Git Flow

2. 发布频率

   • 每天多次发布：Trunk-Based
   • 每周发布：GitHub Flow
   • 每月发布：GitLab Flow
   • 按版本发布：Git Flow

3. 项目类型

   • Web应用：GitHub Flow
   • 移动App：GitLab Flow
   • 企业软件：Git Flow

4. 团队经验

   • 新手多：GitHub Flow（简单）
   • 经验丰富：Git Flow或Trunk-Based

小结

分支策略是团队协作的基石：

• 没有策略：混乱、冲突、风险高
• 有策略：清晰、可控、协作顺畅
• 选择适合的策略：根据团队规模、发布频率、项目类型

接下来的小节，我们详细学习每种策略！

14.2 Git Flow：经典但复杂的分支模型

Git Flow是最早流行起来的分支策略，由Vincent Driessen在2010年提出。它定义了一套完整的分支体系，适合有明确版本发布的项目，比如传统软件、企业应用等。

Git Flow 的分支结构

Git Flow使用五种分支，各司其职：

┌─────────────────────────────────────────────────────────┐
│                      main（主分支）                      │
│                    稳定生产代码，打标签                    │
└───────────────────────┬─────────────────────────────────┘
                        │ 合并release和hotfix
                        ▼
┌─────────────────────────────────────────────────────────┐
│                    develop（开发分支）                   │
│              开发主分支，集成所有功能                     │
└───────────┬───────────────────────────────┬─────────────┘
            │                               │
    ┌───────▼───────┐               ┌──────▼──────┐
    │ feature/*     │               │ release/*   │
    │ 功能分支      │               │ 发布分支    │
    │ 开发新功能    │               │ 准备发布    │
    │ 从develop创建 │               │ 从develop创建│
    │ 合并回develop │               │ 合并到main  │
    └───────────────┘               │ 和develop   │
                                    └─────────────┘
┌─────────────────────────────────────────────────────────┐
│                    hotfix/*（热修复分支）                │
│              紧急修复生产Bug                             │
│              从main创建，合并到main和develop             │
└─────────────────────────────────────────────────────────┘

五种分支详解

1. main（主分支）—— 神圣不可侵犯

• 存放生产环境的代码
• 永远保持稳定，随时可以部署
• 每个提交都对应一个发布版本
• 打上版本标签（tag）：v1.0.0、v1.1.0

1
2
3
4
5

# main分支的提交历史
$ git log --oneline main
a1b2c3d (tag: v1.2.0) Release version 1.2.0
e4f5g6h (tag: v1.1.1) Hotfix 1.1.1
h7i8j9k (tag: v1.1.0) Release version 1.1.0

2. develop（开发分支）—— 开发的主战场

• 开发的主分支，包含最新的开发代码
• 从这里创建feature分支
• 合并到main前，从这里创建release分支
• 比main分支"新"，但可能不稳定

3. feature/*（功能分支）—— 新功能的摇篮

• 用于开发新功能
• 从develop分支创建
• 完成后合并回develop分支
• 命名规范：feature/login、feature/payment

4. release/*（发布分支）—— 发布前的准备

• 准备发布新版本
• 从develop分支创建
• 只修Bug，不加新功能（功能冻结）
• 完成后合并到main和develop
• 命名规范：release/1.0.0、release/1.1.0

5. hotfix/*（热修复分支）—— 紧急救火队

• 紧急修复生产环境的Bug
• 从main分支创建
• 完成后合并到main和develop
• 命名规范：hotfix/1.0.1

Git Flow 完整工作流程

场景1：开始开发新功能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 1. 切换到develop分支
$ git checkout develop

# 2. 拉取最新代码
$ git pull origin develop

# 3. 创建功能分支
$ git checkout -b feature/user-authentication

# 4. 开发功能...
$ git add .
$ git commit -m "Add user login form"
$ git commit -m "Add password validation"
$ git commit -m "Add session management"

# 5. 推送到远程
$ git push origin feature/user-authentication

# 6. 创建Pull Request，请求合并到develop
# 在GitHub/GitLab上操作

# 7. Code Review通过后，合并到develop
$ git checkout develop
$ git merge --no-ff feature/user-authentication

# 8. 删除功能分支
$ git branch -d feature/user-authentication
$ git push origin --delete feature/user-authentication

场景2：准备发布新版本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 1. 从develop创建release分支
$ git checkout develop
$ git pull origin develop
$ git checkout -b release/1.0.0

# 2. 在release分支上准备发布
# - 更新版本号
# - 更新CHANGELOG
# - 修复测试发现的Bug（不能加新功能）
$ git commit -m "Bump version to 1.0.0"
$ git commit -m "Update CHANGELOG"

# 3. 完成后，合并到main
$ git checkout main
$ git merge --no-ff release/1.0.0

# 4. 打标签
$ git tag -a v1.0.0 -m "Release version 1.0.0"
$ git push origin v1.0.0

# 5. 合并回develop（因为release分支可能有Bug修复）
$ git checkout develop
$ git merge --no-ff release/1.0.0

# 6. 删除release分支
$ git branch -d release/1.0.0

场景3：生产环境紧急修复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 1. 从main创建hotfix分支
$ git checkout main
$ git pull origin main
$ git checkout -b hotfix/1.0.1

# 2. 修复Bug
$ git commit -m "Fix critical security vulnerability"

# 3. 合并到main并发布
$ git checkout main
$ git merge --no-ff hotfix/1.0.1
$ git tag -a v1.0.1 -m "Hotfix 1.0.1"
$ git push origin v1.0.1

# 4. 合并到develop（确保develop也有修复）
$ git checkout develop
$ git merge --no-ff hotfix/1.0.1

# 5. 删除hotfix分支
$ git branch -d hotfix/1.0.1

Git Flow 的优点

Git Flow 的缺点

何时使用 Git Flow？

适合：

• ✅ 传统软件项目（桌面应用、企业软件）
• ✅ 有明确发布周期的项目
• ✅ 需要维护多个版本的项目
• ✅ 团队规模较大（10人以上）
• ✅ 对代码质量要求高

不适合：

• ❌ Web应用持续部署
• ❌ 小团队快速迭代
• ❌ 发布频率很高（每天多次）
• ❌ 新手团队

Git Flow 工具

可以使用工具简化Git Flow操作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# 安装git-flow工具
# Mac
$ brew install git-flow-avh

# Linux
$ apt-get install git-flow

# Windows
# 下载安装包

# 初始化Git Flow
$ git flow init

# 开始新功能
$ git flow feature start my-feature

# 完成功能
$ git flow feature finish my-feature

# 开始发布
$ git flow release start 1.0.0

# 完成发布
$ git flow release finish 1.0.0

# 开始热修复
$ git flow hotfix start 1.0.1

# 完成热修复
$ git flow hotfix finish 1.0.1

小结

Git Flow是经典的分支策略：

• 五种分支：main、develop、feature、release、hotfix
• 明确的职责：每种分支有明确用途
• 适合版本发布：有完整的发布流程
• 但较为复杂：需要团队学习和遵守

如果你的项目需要严格的版本管理和发布流程，Git Flow是不错的选择！

下一节，我们来学习更简单的GitHub Flow。

14.3 GitHub Flow：简单就是美

如果你觉得Git Flow太复杂，那GitHub Flow可能更适合你。这是GitHub推荐的分支策略，极其简单，适合持续部署和快速迭代的项目。

GitHub Flow 的核心思想

只有一个长期分支：main

其他都是临时分支，用完即删。简单到令人发指！

main（永远可部署）
  │
  ├── feature-login（临时分支，开发完删除）
  ├── feature-payment（临时分支，开发完删除）
  └── hotfix-bug（临时分支，修复完删除）

GitHub Flow 的六条规则

1. main分支上的任何东西都是可部署的
2. 新功能从main创建新分支
3. 定期向分支推送（备份）
4. 通过Pull Request合并代码
5. PR必须经过Code Review
6. 合并后立即部署

GitHub Flow 工作流程

完整流程：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# 1. 从main创建功能分支
$ git checkout main
$ git pull origin main
$ git checkout -b feature-awesome-feature

# 2. 开发并提交（小步快跑）
$ git add .
$ git commit -m "Add awesome feature"
$ git push origin feature-awesome-feature

# 3. 在GitHub上创建Pull Request
# - 填写PR标题和描述
# - 关联相关Issue
# - 请求Review

# 4. Code Review
# - 团队成员Review代码
# - 提出修改意见
# - 作者修改并推送

# 5. 合并到main
# - 在GitHub上点击Merge
# - 或使用命令行：
$ git checkout main
$ git merge feature-awesome-feature
$ git push origin main

# 6. 立即部署
# - CI/CD自动部署
# - 或手动部署

# 7. 删除功能分支
$ git branch -d feature-awesome-feature
$ git push origin --delete feature-awesome-feature

GitHub Flow 的优点

GitHub Flow 的缺点

何时使用 GitHub Flow？

适合：

• ✅ Web应用（前后端分离）
• ✅ 持续部署（每天多次发布）
• ✅ 快速迭代（敏捷开发）
• ✅ 小团队（1-10人）
• ✅ SaaS产品

不适合：

• ❌ 需要版本发布的软件（如桌面应用）
• ❌ 需要维护多个版本
• ❌ 大型企业软件
• ❌ 没有CI/CD的团队

GitHub Flow vs Git Flow

小结

GitHub Flow简单高效：

• 只有一个main分支
• 功能分支用完即删
• 通过PR合并
• 适合持续部署

如果你的团队做Web应用，追求快速迭代，GitHub Flow是最佳选择！

下一节，我们来学习GitLab Flow。

14.4 GitLab Flow：现代团队的折中方案

GitLab Flow结合了Git Flow和GitHub Flow的优点，既有环境分支的概念，又保持了简单性。它是GitLab推荐的分支策略，适合现代DevOps团队。

GitLab Flow 的分支结构

main（开发分支）
  │
  ├── feature/*（功能分支）
  │
  ├── pre-production（预发布环境）
  │
  └── production（生产环境）

GitLab Flow 的工作流程

1. 功能开发

1
2
3
4
5
6
7

# 从main创建功能分支
$ git checkout main
$ git checkout -b feature-awesome

# 开发...
$ git commit -m "Add awesome feature"
$ git push origin feature-awesome

2. 创建MR（Merge Request）

在GitLab上创建MR，请求合并到main。

3. Code Review

Review通过后，合并到main。

4. 部署到预发布环境

1
2
3
4

# 将main合并到pre-production
$ git checkout pre-production
$ git merge main
$ git push origin pre-production

自动部署到预发布环境，进行测试。

5. 测试通过，部署到生产

1
2
3
4

# 将pre-production合并到production
$ git checkout production
$ git merge pre-production
$ git push origin production

自动部署到生产环境。

环境分支

GitLab Flow支持多个环境分支：

• main：开发环境
• staging：测试环境
• pre-production：预发布环境
• production：生产环境

代码按顺序流动：main → staging → pre-production → production

GitLab Flow 的优点

GitLab Flow 的缺点

何时使用 GitLab Flow？

适合：

• ✅ 有多个环境的项目
• ✅ DevOps团队
• ✅ 需要预发布测试
• ✅ 现代Web应用

小结

GitLab Flow折中方案：

• 环境分支隔离
• 简单灵活
• 适合DevOps

如果你的团队使用GitLab，有多个环境，GitLab Flow是不错的选择！

下一节，我们来学习Trunk-Based Development。

14.5 Trunk-Based Development：主干开发模式

Trunk-Based Development（主干开发）是最激进的分支策略，所有开发者直接在main分支上工作，几乎不使用功能分支。这是Google、Facebook等大公司使用的策略。

核心思想

所有人都在main分支上工作

main（唯一分支）
  │
  ├── 开发者A提交
  ├── 开发者B提交
  ├── 开发者C提交
  └── ...

工作流程

1. 拉取最新代码

1
2

$ git checkout main
$ git pull origin main

2. 小步提交

1
2
3
4

# 修改一小部分代码
$ git add .
$ git commit -m "Small change"
$ git push origin main

3. 频繁提交

每天多次提交，每次提交都很小。

4. 使用Feature Toggle

未完成的功能用开关控制：

1
2
3

if (featureFlags.newFeature) {
  // 新功能代码
}

关键实践

• 小步提交：每次提交只改几行代码
• 频繁集成：每天多次提交到main
• 自动化测试：必须有完善的测试
• Feature Toggle：用开关控制功能发布
• 快速回滚：出问题快速回滚

何时使用 Trunk-Based？

适合：

• ✅ 高频发布（一天多次）
• ✅ 自动化测试完善
• ✅ 团队经验丰富
• ✅ 微服务架构

不适合：

• ❌ 测试不完善
• ❌ 新手团队
• ❌ 需要大改动

小结

Trunk-Based激进高效：

• 所有人主干开发
• 小步频繁提交
• 需要完善测试
• 适合高频发布

下一节，我们来对比永久分支和临时分支。

14.6 永久分支 vs 临时分支：各司其职

分支可以分为永久分支和临时分支，它们有不同的职责和生命周期。

永久分支

定义：一直存在的分支，不会被删除。

常见的永久分支：

永久分支的特点：

• 长期存在
• 有明确的职责
• 代表环境或阶段
• 通常受保护（不能直接推送）

临时分支

定义：临时创建，用完即删的分支。

常见的临时分支：

临时分支的特点：

• 短期存在
• 单一职责
• 完成后删除
• 个人或特性工作区

小结

下一节，我们来学习feature、release、hotfix分支的使用场景。

14.7 feature、release、hotfix：什么时候用什么分支

不同的分支有不同的用途，选择合适的分支类型很重要。

feature分支——开发新功能

什么时候用：

• 开发新功能
• 实验性开发
• 较大的改动

创建：

1

$ git checkout -b feature/user-profile

合并：

1
2

$ git checkout develop
$ git merge feature/user-profile

release分支——准备发布

什么时候用：

• 准备发布新版本
• 版本冻结（不加新功能）
• 测试和修Bug

创建：

1

$ git checkout -b release/1.0.0

合并：

1
2
3

$ git checkout main
$ git merge release/1.0.0
$ git tag v1.0.0

hotfix分支——紧急修复

什么时候用：

• 生产环境紧急Bug
• 安全漏洞
• 严重问题

创建：

1

$ git checkout -b hotfix/1.0.1

合并：

1
2
3
4
5
6

$ git checkout main
$ git merge hotfix/1.0.1
$ git tag v1.0.1

$ git checkout develop
$ git merge hotfix/1.0.1

选择指南

下一节，我们来学习环境对应分支。

14.8 环境对应分支：开发、测试、生产分离

在大型项目中，通常有多个环境，每个环境对应一个分支。

典型环境分支

production（生产环境）
  ↑
staging（预发布/测试环境）
  ↑
develop（开发环境）
  ↑
feature/*（功能分支）

各环境用途

开发环境（develop）：

• 开发人员日常集成
• 最新的开发代码
• 可能不稳定

测试环境（staging）：

• QA测试
• 模拟生产环境
• 预发布版本

生产环境（production）：

• 线上运行的代码
• 稳定可靠
• 用户访问的代码

代码流动

feature分支 ──▶ develop ──▶ staging ──▶ production
  开发           集成         测试         上线

小结

环境分支分离的好处：

• 环境隔离，互不干扰
• 清晰的代码流动
• 便于管理和追溯

下一节，我们来学习如何选择适合团队的策略。

14.9 如何选择适合团队的策略？

选择分支策略要考虑多个因素。

决策树

团队规模？
├── 1-5人 → GitHub Flow 或 Trunk-Based
└── 5+人 → 发布频率？
    ├── 每天多次 → GitHub Flow
    ├── 每周 → GitLab Flow
    └── 按月 → Git Flow

考虑因素

1. 团队规模

• 小团队：简单策略
• 大团队：需要规范

2. 发布频率

• 高频：GitHub Flow
• 中频：GitLab Flow
• 低频：Git Flow

3. 项目类型

• Web应用：GitHub Flow
• 移动App：GitLab Flow

如果你的项目需要