4、分支策略：Git Flow、GitHub Flow、Trunk-Based Development 在嵌入式项目中的选择
说到分支策略，很多团队一开始都觉得「随便选一个就行」。但我在嵌入式项目里吃过不少亏，才明白这事没那么简单。
你想想看，嵌入式开发有个特点：硬件和软件深度耦合。你改一行代码，可能就要重新编译、烧录、测试。如果分支策略选错了，光是合并代码就能让你崩溃。
今天我就把三种主流策略掰开揉碎了讲。结合我自己的踩坑经历，帮你找到最适合嵌入式项目的方案。
4.1 Git Flow：经典但有点重
Git Flow 是 2010 年就提出的老牌策略。它定义了五种分支：master、develop、feature、release、hotfix。
结构大概是这样的：
master
└── develop
├── feature/xxx
├── feature/yyy
└── release/1.0
└── hotfix/1.0.1优点很明显：
- 分支职责清晰，适合大型项目
- 发布流程规范，适合有固定发版周期的产品
- hotfix 分支能快速修复线上问题
但缺点也致命：
- 分支太多，合并频繁，容易出冲突
- 嵌入式项目编译慢，每次合并都要等很久
- 对持续集成不友好，CI 要跑多个分支
我的经验：
我曾经在一个车载项目里用 Git Flow。团队 15 个人，每天光合并代码就要花 2 小时。最惨的一次，feature 分支合并到 develop 时，因为底层驱动改了接口，导致 3 个人的代码全部编译失败。那天我们加班到凌晨 2 点才搞定。
避坑指南：如果你团队小于 10 人，或者项目迭代周期短于 2 周，别用 Git Flow。它太重了。
4.2 GitHub Flow：轻量但太简单
GitHub Flow 是 GitHub 推的简化版。只有 master 和 feature 分支。所有开发都在 feature 分支上做，完成后提 Pull Request，审核通过就合并到 master。
流程很简单：
master
└── feature/xxx (PR → merge)
└── feature/yyy (PR → merge)优点：
- 极其简单，学习成本低
- 适合持续部署，合并即上线
- PR 审核机制能保证代码质量
缺点：
- 没有 release 分支，不适合需要多版本维护的嵌入式产品
- master 必须时刻可部署，但嵌入式项目往往做不到
- 硬件依赖导致测试周期长，PR 审核效率低
我的建议：GitHub Flow 适合纯软件项目，或者硬件已经稳定的嵌入式项目。如果你还在硬件调试阶段，别用这个。
我记得有个做智能家居的朋友，他们用 GitHub Flow。结果有一次硬件改版，驱动代码改了，但 master 上的应用层代码没适配。合并后直接烧录，设备全变砖。嗯，这就是太依赖「合并即上线」的代价。
4.3 Trunk-Based Development：高效但要求高
Trunk-Based Development（主干开发）是我个人最推崇的。所有开发者都在主干（trunk/main）上工作，或者最多开短期分支（不超过 2 天）。
核心思想就一句话：小步快跑，频繁合并。
main
├── commit A
├── commit B
├── commit C (短分支合并)
└── commit D优点：
- 冲突少，因为大家每天都在合并
- CI/CD 友好，每次提交都能触发自动化测试
- 适合敏捷开发，快速响应需求变化
缺点：
- 对团队纪律要求极高，不能有「我先写完了再合并」的想法
- 需要完善的自动化测试和 CI 流水线
- 硬件依赖强的模块，很难做到每天合并
我的经验：
我在一个物联网网关项目里用了 Trunk-Based。团队 8 个人，每天至少合并 3-5 次。刚开始大家很不习惯，觉得「代码还没写完就合并？」。后来我们引入了 feature toggle（特性开关），没写完的功能用开关隐藏起来。效果出奇的好，冲突减少了 80%。
避坑指南：如果你没有完善的 CI 和自动化测试，别碰 Trunk-Based。否则每次合并都是灾难。
4.4 嵌入式项目怎么选？
说了这么多，到底怎么选？我根据项目类型给个参考：
| 项目类型 | 推荐策略 | 理由 |
|---|---|---|
| 车载、工控等安全关键系统 | Git Flow | 需要严格的发布流程和版本管理 |
| 消费电子、IoT 设备 | Trunk-Based | 迭代快，需要快速响应市场 |
| 硬件已稳定的纯软件维护 | GitHub Flow | 简单高效，适合持续部署 |
| 小团队（< 5人）原型开发 | Trunk-Based 或 GitHub Flow | 人少沟通成本低，没必要搞复杂 |
我个人习惯是：核心原则是「能主干就主干，不能主干就 Git Flow」。说白了，Trunk-Based 是理想状态，但现实中很多嵌入式项目因为硬件限制做不到。这时候 Git Flow 反而是最稳妥的选择。
4.5 我的最终建议
如果你现在要选分支策略，我建议你按这个步骤来：
- 先评估你的硬件成熟度。硬件稳定了，才能考虑 Trunk-Based。
- 再看团队规模。超过 10 人，Git Flow 更安全。
- 最后看 CI 能力。没有自动化测试，任何策略都是空谈。
一个小技巧：不管选哪种策略，都建议在项目初期就定好。中途换分支策略，比换技术栈还痛苦。我经历过一次，那感觉就像在高速公路上换轮胎。
嗯，分支策略就讲到这里。下一章我会讲 CI/CD 流水线怎么搭，到时候会结合今天讲的分支策略，给你一套完整的方案。