2. 版本控制与分支策略：Git Flow、GitHub Flow、Trunk-Based Development
版本控制这件事，说白了就是团队协作的「交通规则」。没有规则，大家各开各的车，早晚撞成一团。我见过太多团队，一开始觉得分支策略无所谓，结果上线前合并冲突能搞到凌晨三点。嗯，今天我们就来聊聊三种主流的分支策略，以及怎么选。
2.1 为什么分支策略这么重要？
你想想看，一个团队十几个人，同时开发多个功能。有人修bug，有人做新功能，有人改配置。如果没有统一的分支策略，代码库很快就会变成一团乱麻。
分支策略的核心目标其实就三个：
- 并行开发：多人同时工作，互不干扰
- 代码隔离：未完成的功能不会影响主分支
- 可控发布：知道什么时候该合并，什么时候该发布
我在项目中遇到过最惨的一次，就是因为没有分支策略，两个团队同时改了同一个配置文件，结果上线后数据库连接全断了。从那以后，我对分支策略就特别较真。
2.2 Git Flow：经典但有点重
Git Flow 是 2010 年 Vincent Driessen 提出的。它定义了五种分支：
| 分支类型 | 命名规则 | 用途 |
|---|---|---|
| master | master | 生产环境代码，只接受合并 |
| develop | develop | 日常开发的主分支 |
| feature | feature/xxx | 新功能开发 |
| release | release/x.x.x | 发布前的准备分支 |
| hotfix | hotfix/x.x.x | 紧急修复生产问题 |
Git Flow 的流程大概是这样的：
# 从 develop 创建 feature 分支
git checkout -b feature/user-login develop
# 开发完成后合并回 develop
git checkout develop
git merge --no-ff feature/user-login
# 准备发布时，从 develop 创建 release 分支
git checkout -b release/1.2.0 develop
# 修复 release 分支上的问题后，合并到 master 和 develop
git checkout master
git merge --no-ff release/1.2.0
git tag -a 1.2.0
git checkout develop
git merge --no-ff release/1.2.0Git Flow 的优点：结构清晰，适合有固定发布周期的项目。
Git Flow 的缺点：分支太多，操作复杂。对于持续交付来说，太重了。
注意：我曾经在一个传统企业项目里用 Git Flow，结果团队光是在「这个 bug 该用 hotfix 还是直接改 develop」上就吵了三天。如果你的团队不大，或者发布频率很高，Git Flow 可能不是最佳选择。
2.3 GitHub Flow：轻量级的选择
GitHub Flow 是 GitHub 团队在实践中总结出来的。它比 Git Flow 简单得多：
- 只有一个长期分支：
main（或master） - 所有开发都在 feature 分支上进行
- 通过 Pull Request 进行代码审查
- 合并后立即部署
流程是这样的：
# 从 main 创建 feature 分支
git checkout -b feature/add-payment main
# 开发、提交、推送
git add .
git commit -m "feat: add payment module"
git push origin feature/add-payment
# 在 GitHub 上创建 Pull Request
# 代码审查通过后，合并到 main
# 合并后自动部署我的建议：如果你的团队做的是 SaaS 产品，或者发布频率很高（每天多次），GitHub Flow 是最省心的选择。我现在的团队就用这个，配合 CI/CD，从合并到上线也就几分钟。
2.4 Trunk-Based Development：极简主义
Trunk-Based Development（主干开发）是更激进的做法。所有开发者都在 main 分支上工作，通过短生命周期的 feature 分支或直接提交来协作。
核心原则：
- 分支生命周期不超过几小时
- 频繁合并，避免大冲突
- 配合 feature toggle（特性开关）控制未完成的功能
# 直接从 main 拉取最新代码
git pull origin main
# 做小改动，频繁提交
git add .
git commit -m "fix: correct typo in login form"
git push origin main
# 或者用短分支
git checkout -b fix-login-typo
# 修改代码
git commit -m "fix: correct typo in login form"
git push origin fix-login-typo
# 立即创建 PR，审查后合并关键点：Trunk-Based Development 要求团队有很强的纪律性。代码必须小步提交，不能有「做了一半」的代码留在主分支上。未完成的功能用 feature toggle 隐藏起来。
为什么会有人选择这种看似「激进」的方式？因为它的好处太明显了：
- 合并冲突极少发生
- 持续集成真正落地
- 发布变得非常频繁和可靠
避坑指南：我曾经在一个金融项目里尝试 Trunk-Based Development，结果失败了。原因是团队里有人习惯一次提交几百行代码，导致主分支经常「坏掉」。如果你团队里有人做不到小步提交，先别急着上主干开发。
2.5 怎么选？我的经验总结
说实话，没有「最好」的分支策略，只有「最合适」的。我根据项目类型给个参考：
| 项目类型 | 推荐策略 | 原因 |
|---|---|---|
| 传统企业应用（月/季度发布） | Git Flow | 需要明确的发布流程和版本管理 |
| SaaS / Web 应用（每日多次发布） | GitHub Flow | 轻量、快速、适合持续部署 |
| 成熟团队 / 微服务架构 | Trunk-Based Development | 极致效率，配合 feature toggle 使用 |
| 开源项目 | GitHub Flow 或 Git Flow | 看社区习惯，GitHub Flow 更常见 |
我的建议：如果你刚开始做持续集成，从 GitHub Flow 开始是最稳妥的。它简单、容易理解，而且能让你快速体验到 CI/CD 的好处。等团队成熟了，再考虑要不要转向 Trunk-Based Development。
最后说一句：分支策略是工具，不是目的。别为了用 Git Flow 而用 Git Flow，也别觉得 Trunk-Based Development 就高人一等。关键是找到适合你团队的节奏。嗯，今天就聊到这里，下一章我们讲讲 CI 流水线的具体搭建。