4、分支策略：Git Flow、GitHub Flow、Trunk Based Development在嵌入式项目中的选择。
聊到分支策略，很多嵌入式工程师第一反应是：“不就是建个分支、合个代码吗？搞那么复杂干嘛？”
嗯，我以前也这么想。直到有一次，我在一个智能窗帘项目里，因为分支策略没选好，导致固件版本乱成一锅粥。生产线的工人拿着三四种不同版本的固件在烧录，售后那边又反馈说某个功能时好时坏……那场面，真叫一个头大。
所以今天咱们就好好掰扯掰扯，Git Flow、GitHub Flow、Trunk Based Development（主干开发）这三种主流分支策略，在嵌入式项目里到底该怎么选。
先说说这三种策略是啥
说白了，这三种策略代表了三种不同的开发节奏和协作方式。我简单给你概括一下：
- Git Flow：分支多，规矩多。有master、develop、feature、release、hotfix等分支。适合版本周期长、需要严格管控的项目。
- GitHub Flow：轻量级。只有一个主干（main），所有开发都在feature分支上做，然后提Pull Request合并。适合持续部署、快速迭代的团队。
- Trunk Based Development：更激进。所有开发者直接在主干上提交，或者只开短期分支（不超过几天）。强调小步快跑，频繁集成。
你想想看，这三种策略，哪一种更适合咱们嵌入式开发？
嵌入式项目的特殊性
嵌入式项目跟纯软件项目不一样。我遇到过不少团队，直接把互联网那套分支策略搬过来，结果水土不服。
嵌入式项目有几个特点：
- 硬件依赖性强：代码跟硬件绑定，不是随便拉个分支就能跑起来的。
- 版本发布周期长：从开发到测试到量产，往往需要几周甚至几个月。
- 需要维护多个版本：比如老版本还在产线上跑，新版本已经在开发了。
- 固件烧录风险高：一旦合错代码，烧到芯片里，可能就得返工。
所以，选分支策略不能只看流行，得看合不合适。
Git Flow：适合复杂嵌入式项目
我个人习惯在大型嵌入式项目里用Git Flow。为什么？因为它结构清晰，责任明确。
举个例子，我们做窗帘电机的主控固件。开发周期大概三个月，中间要经历：
- 功能开发（电机控制算法、蓝牙通信、传感器采集）
- 硬件联调（不同批次电机、不同型号的霍尔传感器）
- 稳定性测试（长时间运行、异常断电、堵转保护）
- 量产准备（固件锁定、生产测试工具）
用Git Flow，我们可以这样安排：
| 分支 | 用途 | 嵌入式场景举例 |
|---|---|---|
| master | 只存放已发布的稳定版本 | 量产固件v1.0、v1.1 |
| develop | 日常开发集成分支 | 所有新功能合入这里 |
| feature/* | 每个功能独立开发 | feature/ble-ota、feature/motor-calibration |
| release/* | 发布前的测试和修复 | release/v1.2-rc1 |
| hotfix/* | 紧急修复线上问题 | hotfix/crash-on-power-loss |
重点来了：在嵌入式项目里，release分支特别有用。因为硬件联调经常发现新问题，你不能直接在主分支上改，否则会影响其他开发。release分支就是给测试和修复留的缓冲区。
不过Git Flow也有缺点——分支太多，合并起来挺麻烦的。小团队或者快速原型阶段，用起来会觉得有点重。
GitHub Flow：适合快速原型和小团队
如果你在做的是一个小型窗帘电机控制器，团队就两三个人，开发周期一两周。那GitHub Flow就够用了。
它的核心思想很简单：
- 所有开发都在feature分支上做
- 完成后提Pull Request
- 代码审查通过后合并到main
- 合并即部署
我在一个快速验证项目里用过这个策略。当时我们要测试一种新的电机驱动方案，从写代码到出固件，只用了三天。GitHub Flow的轻量特性让我们能快速试错。
小提示：用GitHub Flow时，一定要保证main分支随时是可发布状态。嵌入式项目里，这意味着每次合并前，代码必须在目标硬件上通过基本测试。别光在PC上编译通过就合，那会出事的。
但说实话，如果项目涉及到多个硬件版本（比如不同批次的电机、不同型号的传感器），GitHub Flow就有点吃力了。因为main分支只有一个，你很难同时维护多个固件版本。
Trunk Based Development：适合持续集成成熟度高的团队
Trunk Based Development，说白了就是所有开发者都在主干上提交代码。听起来很吓人，对吧？
我刚开始也觉得这不靠谱。但后来在一些对质量要求极高的项目里（比如汽车电子、工业控制），我发现它其实很有价值。
为什么？因为它强制你频繁集成，频繁测试。任何代码提交，都会触发自动化构建和测试。一旦发现问题，立刻修复。
在窗帘电机项目里，如果你能做到：
- 每次提交都通过编译
- 每次提交都在真实硬件上跑过单元测试
- 每次提交都通过静态代码检查
那Trunk Based Development确实能带来极高的开发效率。
注意：Trunk Based Development对自动化测试的要求非常高。我曾经在一个团队里推行过，结果因为硬件测试环境搭建不完善，导致主干频繁被破坏。后来我们不得不退回到Git Flow。
所以，如果你的团队还没有完善的CI/CD流水线，别轻易尝试Trunk Based Development。
我的选择建议
说了这么多，到底该怎么选？我根据自己的经验，给你一个参考：
| 项目类型 | 推荐策略 | 理由 |
|---|---|---|
| 量产级嵌入式产品（如窗帘电机、智能家居网关） | Git Flow | 版本管控严格，支持多版本维护，适合长周期开发 |
| 快速原型、小团队、短期项目 | GitHub Flow | 轻量灵活，快速迭代，适合验证想法 |
| 高可靠性、持续集成成熟、团队经验丰富 | Trunk Based Development | 强制集成，质量高，适合对稳定性要求极高的场景 |
其实没有绝对的好坏。我见过用Git Flow把项目管得一团糟的，也见过用Trunk Based Development做得风生水起的。关键还是看你的团队和项目特点。
避坑指南
最后，分享几个我踩过的坑：
- 分支策略定了就别轻易改：我曾经在一个项目中途从Git Flow切到GitHub Flow，结果历史记录乱得一塌糊涂，团队成员也无所适从。
- 别把硬件配置放在代码分支里：有些团队喜欢为不同硬件版本建不同分支，这是个大坑。应该用配置文件或宏定义来区分硬件版本，而不是用分支。
- 合并前一定要在真实硬件上测试：纯软件项目可以在CI里跑单元测试，但嵌入式项目不行。至少要在目标硬件上跑一遍基本功能测试，再合并。
- 分支命名要有规范：比如feature/xxx、bugfix/xxx、hotfix/xxx。别用“test1”、“new_branch”这种名字，三个月后你自己都看不懂。
嗯，关于分支策略的选择，今天就聊到这儿。记住，没有银弹，只有最适合你的策略。下一章咱们聊聊版本号管理，这个在嵌入式项目里也经常让人头疼。