3、Git工作流设计：GitFlow、GitHub Flow、Trunk Based Development，嵌入式团队如何选择
聊到嵌入式团队的Git工作流，我见过太多团队在这个问题上栽跟头了。有的团队死磕GitFlow，结果每次合并都像在打仗；有的团队盲目跟风Trunk Based，结果固件一发布就出问题。说白了，没有银弹，只有最适合你团队的那一套。
今天我就把三种主流工作流掰开揉碎讲清楚，结合我在嵌入式项目中的实际踩坑经验，帮你找到最适合的那条路。
3.1 三种工作流的核心差异
先看一张对比表，心里有个底：
| 特性 | GitFlow | GitHub Flow | Trunk Based Development |
|---|---|---|---|
| 分支数量 | 多（5+种分支） | 少（主分支+特性分支） | 极少（主干+短期分支） |
| 发布频率 | 低（按版本发布） | 高（持续发布） | 极高（每日多次） |
| 适合场景 | 有固定发布周期的产品 | Web应用、SaaS服务 | 需要快速迭代的团队 |
| 嵌入式适配度 | ★★★★☆ | ★★☆☆☆ | ★★★☆☆ |
| 学习成本 | 高 | 低 | 中 |
3.2 GitFlow：老牌经典，但别照搬
GitFlow是我最早接触的工作流。它把分支分成了master、develop、feature、release、hotfix五类。听起来很完善对吧？但我在嵌入式项目里吃过它的亏。
我曾经在一个车载项目里严格按GitFlow来。结果呢？每次从develop合并到master，都要处理几十个冲突。嵌入式代码里那些宏定义、寄存器地址，冲突起来简直要命。更麻烦的是，release分支一旦创建，hotfix就得同时在两个分支上改，稍不留神就漏了。
不过话说回来，GitFlow对嵌入式团队也有它的价值：
- 版本管理清晰：每个release分支对应一个固件版本，方便回溯
- 支持多版本维护：老版本出bug了，可以从对应release分支拉hotfix
- 适合硬件依赖强的项目：硬件版本变更时，可以独立维护分支
3.3 GitHub Flow：轻量但不够用
GitHub Flow就简单多了——只有一个master分支，所有开发都在特性分支上完成，通过Pull Request合并。我刚开始也觉得这玩意儿太适合嵌入式了，直到有一次...
我记得有个智能家居项目，团队用了GitHub Flow。大家往master上合代码特别积极，结果某天下午，一个同事合了个改了GPIO引脚配置的PR，直接导致另一块板子的传感器驱动全挂了。因为没有预发布分支，问题直到烧录到测试板才发现。
GitHub Flow的问题在于：
- 没有预发布环境：嵌入式不像Web可以灰度发布，固件烧进去就回不来了
- 不适合硬件依赖：不同硬件版本需要不同固件，一个master分支管不过来
- 回滚成本高：嵌入式回滚往往要重新烧录，不像Web一键回退
3.4 Trunk Based Development：快，但有门槛
Trunk Based Development（主干开发）是我现在最推崇的方式。所有开发者都在主干上工作，分支存活时间不超过一天。听起来很激进对吧？但配合特性开关（Feature Toggle），它其实很安全。
我个人习惯在嵌入式项目里这样用：
# 主干开发的基本流程
1. 从主干拉取短期分支（不超过一天）
2. 开发完成后，通过CI跑完整测试
3. 代码审查通过后，合并回主干
4. 使用特性开关控制未完成的功能
5. 每天至少合并一次到主干你可能会问：「嵌入式代码那么复杂，一天能合一次？」嗯，这里要注意——关键在于小步提交。不要等一个功能全写完再合，而是拆成多个小任务，每个任务都能独立编译通过。
Trunk Based Development的优势很明显：
- 冲突少：因为经常合并，代码差异小
- 集成快：每天都能拿到可运行的固件
- 适合CI/CD：每次提交都能触发自动化测试
但门槛也不低：
- 需要完善的CI：没有自动化测试，主干分分钟崩掉
- 需要特性开关：未完成的功能必须能通过开关隐藏
- 团队纪律要求高：不能有人「偷偷」在本地攒代码
3.5 嵌入式团队怎么选？我的决策框架
说了这么多，到底怎么选？我总结了一个简单的决策树：
- 团队小于5人，产品单一 → 用Trunk Based Development，配合特性开关
- 团队5-15人，有固定版本 → 用简化版GitFlow（去掉develop分支）
- 团队大于15人，多硬件版本 → 用GitFlow完整版，但一定要自动化合并
- 纯软件嵌入式（如RTOS应用） → 可以考虑GitHub Flow，但要有预发布分支
我个人习惯是这么做的：不管选哪种工作流，都先跑一个月试试。如果团队抱怨合并痛苦，就缩短分支存活时间；如果发布总出问题，就增加预发布环节。说白了，工作流是服务人的，不是人服务工作流。
3.6 总结一下
三种工作流没有绝对的好坏。GitFlow适合需要严格版本管理的场景，GitHub Flow适合快速迭代的纯软件项目，Trunk Based Development则是持续集成的终极形态。
对于嵌入式团队，我的建议是：从简化版GitFlow起步，逐步向Trunk Based Development演进。别一上来就搞最复杂的，也别为了追求「先进」而牺牲稳定性。你想想看，嵌入式产品出了问题，可不是重启服务器就能解决的——那是要重新烧录、重新测试、甚至重新流片的。
最后送大家一句话：工作流是工具，不是信仰。适合你的，就是最好的。