3、分支策略：Git Flow、GitHub Flow、Trunk Based Development，哪种适合嵌入式理疗仪？
说实话，每次跟团队聊分支策略，我都觉得有点像在选交通工具。你要去的地方不同，带的行李不同，选的车自然也不一样。Git Flow 像一辆重型卡车，GitHub Flow 像一辆小轿车，Trunk Based Development 则像一辆赛车。那咱们嵌入式理疗仪项目，到底该开哪辆车？
我个人习惯是，先看产品特点，再看团队规模，最后才定策略。理疗仪这东西，说复杂也复杂，说简单也简单。它不像手机系统那样天天发版，也不像航天软件那样几年才更新一次。它有自己的节奏——硬件迭代慢，固件迭代快，而且必须保证安全。
先看看这三种策略长什么样
我简单画个对比，你心里就有数了。
| 策略 | 核心思想 | 分支数量 | 适合场景 |
|---|---|---|---|
| Git Flow | 多分支并行，严格区分开发、发布、修复 | 5+ 条常驻分支 | 大型项目、固定版本发布 |
| GitHub Flow | 只有 main 分支，功能分支合并即发布 | 2 条常驻分支 | 持续部署、Web 应用 |
| Trunk Based | 所有人往主干合并，短生命周期分支 | 1 条常驻分支 | CI/CD 成熟、小团队 |
嗯，光看表格可能有点抽象。我拿实际项目说说感受。
Git Flow：太沉了，但有些场景真离不开
我记得刚入行那会儿，带我的老工程师特别推崇 Git Flow。他总说：「分支分得越细，心里越踏实。」那时候我们做的是医疗监护仪，确实需要这种严谨。
Git Flow 有 master、develop、feature、release、hotfix 五类分支。每次发版，都要从 develop 拉一个 release 分支，测试通过后再合并到 master 打 tag。
对于理疗仪来说，这种策略的好处很明显：
- 版本回溯清晰——每个 tag 对应一个正式发布版本，出了事能快速定位
- 热修复隔离——线上出 bug，从
master拉hotfix分支修，不影响正在开发的新功能 - 适合合规审计——医疗器械行业经常要查「这个版本是谁改的、为什么改」，Git Flow 的分支历史一清二楚
但问题也来了。理疗仪的固件团队通常不大，3-5 个人。搞 5 条常驻分支，光合并就能把人搞疯。我曾经在一个项目里，光 release 分支合并就花了三天，因为冲突太多。你想想看，一个小团队，每天花大量时间在合并上，值吗？
GitHub Flow：轻量，但太「Web」了
GitHub Flow 是我见过最清爽的策略。只有一条 main 分支，所有开发都在功能分支上完成，提 PR，review 通过后合并，然后直接部署。
听起来很美好对吧？但我在嵌入式项目里试过一次，差点翻车。
为什么？因为嵌入式软件有个特点——烧录成本高。Web 应用改一行代码，刷新页面就生效。理疗仪改一行代码，你得编译、链接、烧录、重启、测试，这一套下来少说 10 分钟。如果每次合并都直接部署，那测试团队根本跟不上节奏。
而且，理疗仪的固件经常需要做「版本锁定」。比如某个批次的硬件有改动，固件必须用特定版本。GitHub Flow 那种「合并即发布」的节奏，很难管理这种多版本并行的情况。
Trunk Based Development：快，但需要纪律
Trunk Based Development，说白了就是所有人往主干上怼代码。分支存活时间不超过一天，每天至少合并一次。
我第一次接触这个策略时，心里是拒绝的。心想：「这不乱套了吗？」后来在一个做智能穿戴设备的项目里被迫用了三个月，才发现——真香。
对于理疗仪来说，Trunk Based 有几个关键优势：
- 集成冲突少——每天合并，代码差异小，冲突基本没有
- 问题发现早——今天改的代码，明天测试就能跑，不用等两周
- 适合敏捷开发——理疗仪的功能迭代通常是小步快跑，比如「优化电极检测算法」「调整 PWM 频率」，这种改动一天就能搞定
但注意，Trunk Based 有个前提——自动化测试必须到位。我曾经在一个项目里，因为单元测试覆盖率只有 30%，用 Trunk Based 直接导致主干三天两头挂掉。后来花了两个月补测试，才稳定下来。
那理疗仪到底选哪个？
我直接给结论吧，不绕弯子。
场景一：产品处于研发阶段，硬件还没定型
选 Trunk Based Development。因为这时候变化最快，今天改个传感器驱动，明天换个 MCU 型号，分支多了全是负担。我建议只保留 main 分支，功能分支存活不超过 2 天。
场景二：产品已经量产，需要维护多个硬件版本
选 Git Flow。这时候你需要同时维护 v1.0、v1.1、v2.0 等多个版本，每个版本对应不同的硬件批次。Git Flow 的 release 和 hotfix 分支正好派上用场。
场景三：团队 10 人以上，有专门的测试和发布流程
选 Git Flow 的简化版。去掉 release 分支，用 tag 代替。保留 develop 和 master，功能分支从 develop 拉，合并后自动触发测试。这是我个人最常用的方案，既保留了 Git Flow 的严谨，又没那么重。
场景四：纯 App 或上位机软件迭代
选 GitHub Flow。因为 App 的发布周期短，而且可以灰度发布、热更新。GitHub Flow 的轻量特性在这里发挥得淋漓尽致。
避坑指南
最后分享几个我踩过的坑，你遇到了能少走弯路。
- 在 Trunk Based 里搞「周五合并」——周五下午合并代码，周末出 bug，周一早上被测试追着骂。后来我规定：周五只修 bug，不合并新功能。
- Git Flow 的
release分支存活太久——有一次release分支活了两个月，跟develop的差异越来越大，最后合并时冲突多到想哭。现在我要求release分支最多活两周。 - GitHub Flow 没有做 feature flag——直接合并到
main后，新功能自动上线，结果硬件还没到货。后来加了 feature flag，功能合并但不激活，等硬件到位再打开。
嗯，说了这么多，其实就一句话：没有最好的策略，只有最合适的。理疗仪这个品类，安全第一，迭代第二。选分支策略时，先问自己三个问题：
- 这个版本需要同时维护几个硬件版本？
- 自动化测试覆盖了多少？
- 团队每天能合并几次代码？
想清楚这三个问题，答案自然就出来了。