Git工作流与分支策略：从混乱到有序的进化之路
聊到Git工作流，我脑子里第一个蹦出来的画面是——刚入行那会儿，团队十几号人全在master上直接提交。你想想看，那场面有多刺激？每次合并都像在拆弹，动不动就「哎呀冲突了」、「谁又把我的代码覆盖了」。后来我才明白，分支策略不是技术问题，是协作问题。
今天咱们就把主流的三种工作流掰开揉碎，再聊聊分支保护和Code Review那些事儿。嗯，都是我在项目里踩过坑、填过土之后总结出来的。
一、Git Flow：经典但有点重
Git Flow是2010年Vincent Driessen提出的模型。说实话，它很完整，但也确实复杂。
它的核心分支结构是这样的：
master（生产分支）
↑
release（发布候选分支）
↑
develop（开发主分支）
↑
feature/*（功能分支）
hotfix/*（热修复分支，直接从master拉）关键角色：
- master：只存可发布的代码。每次合并都打tag
- develop：日常开发的主战场
- feature/*：每个新功能一个分支，开发完合并回develop
- release/*：准备发布时从develop拉，只修bug，不添新功能
- hotfix/*：线上出问题，从master拉，修完合并回master和develop
我个人习惯：Git Flow适合有固定发布周期的项目，比如一个月发一个版本。但如果你团队每天发多次，这玩意儿就太重了。
避坑指南：我曾经在一个创业团队里硬推Git Flow，结果光分支管理就花掉20%的时间。后来我学乖了——流程是为效率服务的，不是反过来。
二、GitHub Flow：轻量级的选择
GitHub Flow就简单多了。说白了，它只有一条铁律：任何改动都从master拉分支，做完提PR，审核通过就合并。
流程长这样：
- 从master拉一个功能分支
- 在分支上提交代码
- 开一个Pull Request
- 团队Review、讨论、修改
- 合并回master
- 立刻部署
你可能会问：「没有develop分支，那开发中的代码放哪？」
答案是——放PR里。GitHub Flow的理念是：分支的生命周期很短，功能开发完就合并，绝不养长期分支。
我建议：如果你的团队做SaaS产品、持续部署，GitHub Flow是最佳选择。我在一个日活百万的项目里用过，配合CI/CD，从提PR到上线平均只要40分钟。
三、Trunk-Based Development：极简主义
Trunk-Based Development（TBD）更激进。所有开发者都在主干（trunk/main）上工作，分支要么不存在，要么只存活几小时。
核心规则：
- 主干永远是可发布的状态
- 分支（如果有）不能超过2天
- 每次提交都经过自动化测试
- 频繁合并，避免大冲突
注意：TBD对团队要求极高。你想想看，如果测试覆盖率不够，或者CI跑得慢，那主干分分钟就崩了。我见过一个团队硬上TBD，结果每天要回滚3次……
三种工作流对比一下：
| 特性 | Git Flow | GitHub Flow | TBD |
|---|---|---|---|
| 分支数量 | 多（长期+短期） | 少（仅短期） | 极少（几乎无） |
| 发布频率 | 低（周/月） | 高（天/小时） | 极高（持续） |
| 团队规模 | 中大型 | 中小型 | 小型精英 |
| 学习成本 | 高 | 低 | 中 |
| 冲突风险 | 低 | 中 | 高 |
四、分支保护规则：别让任何人搞砸主干
不管你选哪种工作流，分支保护规则都是必须的。说白了，就是给主干加几道锁。
我常用的保护规则：
- 禁止直接推送：master/main只能通过PR合并
- 要求PR审核：至少1-2人批准才能合并
- 状态检查通过：CI/CD必须全绿
- 分支必须最新：合并前要rebase或merge最新的master
- 对话已解决：所有评论都处理完
我曾经在一个项目里没开「要求分支最新」这个规则。结果有人基于两周前的master做了个大改动，合并时冲突多到让人崩溃。从那以后，我所有项目都把这个规则勾上。
五、Code Review流程：不只是找bug
很多人觉得Code Review就是找bug。其实不然，它有三个核心价值：
- 知识传递：新人通过Review学习代码规范
- 质量把关：发现逻辑漏洞、安全隐患
- 团队共识：统一编码风格和设计思路
我建议的Review流程：
- PR描述要清晰：写清楚「改了啥、为什么改、怎么测试」
- Reviewer要专注：一次Review不超过200行代码，超过就分批
- 评论要对事不对人：说「这个函数可以优化」而不是「你写得不对」
- 24小时内响应：拖太久会阻塞开发进度
- 合并后清理分支：保持仓库整洁
小技巧：我习惯在PR模板里加一个checklist，让提PR的人自己先检查一遍。比如「单元测试写了没？」、「有没有引入新的依赖？」。这能省掉Reviewer很多时间。
六、如何选择？我的建议
没有银弹。我见过用Git Flow的团队效率很高，也见过用TBD的团队天天吵架。关键看这几点：
- 发布频率：每天发 → GitHub Flow或TBD；每月发 → Git Flow
- 团队规模：10人以下 → 轻量级；50人以上 → 需要更严格的分支管理
- 项目阶段：初创期 → 快最重要；成熟期 → 稳最重要
- 自动化程度：CI/CD完善 → 可以上TBD；测试覆盖率低 → 老老实实用Git Flow
嗯，最后说一句：工具是死的，人是活的。别为了用某个工作流而用，要根据实际情况调整。我见过最成功的团队，往往是那些能把流程简化到极致、同时又不牺牲质量的团队。
下一章咱们聊聊CI/CD流水线的搭建，到时候我会分享一些我在生产环境里踩过的坑——嗯，保证让你少走弯路。