版本控制与分支策略：选对路子，少踩坑
说到 CI/CD，版本控制是地基。地基不稳，上面盖什么都白搭。我个人习惯，不管项目大小，先把分支策略定明白。不然哪天合并冲突能把人逼疯。
为什么分支策略这么重要？
你想想看，团队十来号人，每天向同一个仓库推代码。如果没个规矩，谁改了谁的文件都不知道。我见过一个项目，所有人都在 master 上直接开发，结果上线前两天乱成一锅粥。嗯，从那以后我就特别强调分支策略。
说白了，分支策略就是一套“交通规则”。它决定了：
- 什么分支用来开发？
- 什么分支用来测试？
- 什么分支用来发布？
- 代码怎么从开发流到生产？
三种主流分支模型
我这些年用过不少模型，总结下来最常用的就三种：Git Flow、Trunk-Based Development（主干开发）、GitHub Flow。下面我一个个讲。
1. Git Flow —— 老派但可靠
Git Flow 是 2010 年提出的，现在很多大厂还在用。它把分支分得很细：
- master：只存已发布的代码，不能直接提交。
- develop：日常开发的主分支，所有功能分支从这拉。
- feature/xxx：每个新功能一个分支，开发完合并回 develop。
- release/x.x：准备发布时从 develop 拉出来，只做 bug 修复和文档。
- hotfix/xxx：线上紧急修复，从 master 拉，修完合并回 master 和 develop。
我在项目中遇到过一个大痛点：feature 分支存活周期太长。有时候一个功能开发两周，合并时已经跟 develop 差了几百个 commit。冲突解决得想哭。所以我现在只推荐在以下场景用 Git Flow：
- 有固定发布周期的产品（比如每两周发一个版本）
- 需要同时维护多个版本（比如 v1.0、v1.1 都在线上）
- 团队规模较大（20人以上）
2. Trunk-Based Development —— 敏捷利器
说白了就是所有人在一个主干上开发，分支少，合并频繁。我最近几年特别喜欢这个模型，尤其是在做微服务的时候。
核心原则：
- 所有开发者都往 main（或 trunk）上提交代码。
- 分支尽可能短命，最多一两天。
- 通过特性开关（Feature Toggle）控制未完成的功能，而不是靠分支保护。
- 每次提交都触发 CI 构建和自动化测试。
# 典型工作流程
git checkout main
git pull origin main
# 写代码...
git commit -am "feat: add user login"
git push origin main # 直接推主干
你可能会问：“直接推主干，不怕坏代码进去吗？”答案是：怕，所以要靠 CI 和代码审查。我们团队的做法是：
- 提交前本地跑一遍完整的测试套件。
- 推到主干后自动触发 CI 流水线。
- 如果 CI 失败，马上修复，绝不让坏代码留在主干上超过 10 分钟。
3. GitHub Flow —— 简单粗暴
GitHub 官方推荐的模型，比 Git Flow 轻量，比 TBD 多了 Pull Request 机制。我个人习惯在小团队（5 人以内）或者开源项目里用这个。
- 只有一个长期分支 main。
- 所有开发从 main 拉新分支（feature/xxx 或 fix/xxx）。
- 在分支上开发，提交 Pull Request 请求合并。
- PR 通过代码审查和 CI 后，合并回 main。
- 合并后立即删除分支。
# GitHub Flow 示例
git checkout -b feature/add-payment
# 写代码...
git push origin feature/add-payment
# 在 GitHub 上创建 PR
# 等审核通过后合并
git checkout main
git pull origin main
git branch -d feature/add-payment
三种模型对比
| 维度 | Git Flow | Trunk-Based Dev | GitHub Flow |
|---|---|---|---|
| 分支数量 | 多（master, develop, feature, release, hotfix） | 极少（main + 短命分支） | 少（main + 功能分支） |
| 分支存活期 | 长（feature 几天到几周） | 短（不超过 1-2 天） | 短（PR 完成即删） |
| 发布频率 | 低（定期发布） | 高（每天多次） | 中等（功能完成即发） |
| 适合团队 | 大型、多版本 | 快速迭代、高度自动化 | 小团队、开源 |
| 冲突风险 | 高（长期分支） | 低（频繁合并） | 中（看 PR 时长） |
选型建议
我一般这样给团队建议：
- 新产品、快速迭代 → 用 Trunk-Based Development。配合特性开关和自动化测试，每天可以发布几十次。
- 成熟产品、有固定版本 → 用 Git Flow。尤其是需要同时维护 LTS 版本的项目。
- 小团队或开源项目 → 用 GitHub Flow。简单直接，PR 是很好的代码审查入口。
Git 工作流与 CI/CD 的配合
分支策略定了，CI/CD 流水线才能设计好。你想想看，如果用的是 Git Flow，你在 develop 分支上就应该跑完整的测试和构建，而 master 分支的流水线则要加上生产部署的步骤。如果用的是 TBD，每次提交到 main 都得触发完整的 CI 管线。
我在项目中遇到过一个问题：CI 流水线跟分支策略脱节。比如有人把 hotfix 分支合并到 master 后，流水线没有触发生产部署，结果等了半小时才发现。后来我加了 webhook 监听特定条件：
# 示例：GitLab CI 中的规则配置
job:deploy:
script: ./deploy.sh
only:
- master
- /^release\/.*$/
- /^hotfix\/.*$/
这样保证只有 master、release、hotfix 分支才会触发部署，develop 和 feature 分支只跑测试。嗯，清晰多了。
核心逻辑总览
最后说两句
分支策略没有银弹。Git Flow 稳但重，TBD 快但要求高，GitHub Flow 简单但功能有限。我建议你根据团队的实际交付节奏、自动化测试成熟度、线上运维能力来选择。别听别人说哪个好就无脑用——你想想看，一个每周才发一次版的传统项目，硬上 TBD 不是自找麻烦吗？