4、Git工作流与分支策略：Git Flow、GitHub Flow、Trunk-Based Development，如何选择适合团队的分支模型
聊到CI/CD，分支策略是绕不开的话题。我见过太多团队，工具链搭得挺漂亮，结果被分支模型拖了后腿。说白了，分支策略决定了你的代码怎么流、冲突怎么解、发布怎么搞。今天咱们就掰扯清楚三种主流模型，以及怎么给团队挑一个合适的。
4.1 三种主流分支模型速览
先给个全景图。这三种模型各有各的脾气，没有绝对的好坏，只有合不合适。
| 模型 | 核心思想 | 分支数量 | 适合场景 |
|---|---|---|---|
| Git Flow | 严格区分功能、发布、热修复 | 多（5+种分支） | 大型项目、固定版本发布 |
| GitHub Flow | 一切从main出发，PR驱动 | 少（主要就main+功能分支） | 持续部署、小团队 |
| Trunk-Based | 所有人往主干合并，短命分支 | 极少（主干+极短功能分支） | 高频发布、DevOps成熟团队 |
4.2 Git Flow：经典但有点重
Git Flow是2010年Vincent Driessen提出的。说实话，当年我刚接触时觉得这玩意儿太完美了——develop、feature、release、hotfix、master，各司其职。我在一个传统软件公司用过两年，确实稳，但也确实累。
它的分支结构长这样：
master（生产分支）
└── develop（开发主干）
├── feature/xxx（功能分支）
├── release/x.x（发布分支）
└── hotfix/xxx（热修复分支）优点很明显：
- 职责清晰，每个人都知道该往哪合并
- 支持并行开发多个版本
- 热修复可以绕过开发流程直接进生产
但坑也不少：
- 分支太多，合并操作频繁，冲突概率高
- release分支的存在让CI/CD变得复杂——你想想看，CI要同时监听develop、release、hotfix三个分支的构建
- 不适合每天多次发布的场景
4.3 GitHub Flow：轻量但需要纪律
GitHub Flow是GitHub团队自己用的模型。说白了就是：所有开发都从main分支拉功能分支，提PR，Code Review，合并回main，然后自动部署。
流程很简单：
main（永远可部署）
└── feature/xxx（功能分支）
└── PR → Code Review → 合并 → 自动部署我个人的习惯是：功能分支的生命周期不超过两天。超过两天，要么功能太大需要拆分，要么开发节奏有问题。
GitHub Flow的优势：
- 简单，新人上手快
- 天然适配CI/CD——合并即部署
- PR是代码质量的守门员
但要注意几个前提：
- 你的main分支必须时刻保持可部署状态
- 功能开关（Feature Toggle）是必需品，否则半成品功能没法上线
- 团队需要较强的自律性，不能把半拉子代码合并进去
4.4 Trunk-Based Development：极简但要求高
Trunk-Based Development，简称TBD。核心就一句话：所有人直接往主干（trunk/main）提交代码，分支的生命周期以小时计。
我最早接触TBD是在一家做SaaS的公司。说实话，刚开始很不适应——没有develop分支，没有release分支，所有人都在main上干活。但习惯了之后，真香。
TBD有两种常见模式：
- 直接提交模式：开发者直接往main提交，适合极小型团队（2-3人）
- 短命分支模式：从main拉分支，几小时内合并回去，适合中型团队
main（唯一主干）
└── feature/xxx（存在时间 < 4小时）
└── 合并回main → 自动构建 → 自动部署TBD的硬性要求：
- 功能开关必须到位，否则未完成的功能会破坏生产环境
- 自动化测试覆盖率要高（我建议至少80%以上）
- CI流水线要快——超过10分钟，开发者就会不耐烦
- 团队要有「小步提交」的习惯
我的经验之谈：TBD最适合每天发布多次的团队。如果你还在做月度发布，别碰TBD，它会让你痛不欲生。但如果你能做到每天发布3次以上，TBD能极大减少合并冲突——因为大家的代码永远是最新的。
4.5 如何选择？一个决策框架
讲了这么多，到底怎么选？我一般会问团队三个问题：
- 发布频率是多少？
- 团队规模有多大？
- DevOps成熟度如何？
根据答案，可以这样选：
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 月度发布，大型团队（20+人） | Git Flow | 分支隔离好，适合并行开发多个版本 |
| 每周发布，中型团队（5-15人） | GitHub Flow | 简单，PR驱动，质量有保障 |
| 每日多次发布，小型团队（3-8人） | Trunk-Based | 极简，冲突少，适合高频迭代 |
| 创业公司，快速验证阶段 | GitHub Flow 或 TBD | 别在分支管理上浪费时间 |
| 传统企业，合规要求高 | Git Flow（简化版） | 审计需要，分支记录清晰 |
4.6 我的建议：别死磕，可以混搭
说实话，我见过很多团队把Git Flow用成了灾难，也见过把TBD用成了混乱。模型只是工具，关键看你怎么用。
我个人比较推荐的做法是：
- 从GitHub Flow起步，因为它最简单，容易上手
- 随着团队变大，可以引入简化版的Git Flow——去掉release分支，用标签代替
- 如果团队DevOps成熟度够了，逐步向TBD演进
避坑指南：不管你选哪种模型，一定要在CI/CD流水线里体现出来。比如Git Flow，你的CI要同时监听develop和master；GitHub Flow，合并到main就要触发部署；TBD，每次提交都要跑全量测试。分支策略和CI/CD是绑定的，别分开考虑。
最后说一句：没有完美的分支模型，只有适合你团队当前阶段的模型。别为了用某个模型而用，先搞清楚你们的问题是什么——是发布太慢？冲突太多？还是质量不可控？对症下药，比盲目跟风强得多。