4. 分支管理策略：Git Flow、GitHub Flow 在嵌入式固件开发中的应用

说到分支管理，我见过太多团队在这上面栽跟头了。有的项目分支乱得像蜘蛛网，有的干脆就一个 master 分支裸奔。嗯，这两种极端都不对。嵌入式固件开发有其特殊性——硬件依赖、多版本并存、紧急修复频繁，选对分支策略能让你少掉不少头发。

4.1 为什么嵌入式开发需要分支策略？

你想想看，一个嵌入式项目通常要同时维护多个硬件版本。老产品还在产线上跑，新版本已经在开发了。中间还可能冒出个紧急 bug，需要立刻修复。没有分支管理，这些工作全挤在一个分支上，不出乱子才怪。

我个人习惯把分支策略比作「交通规则」。没有规则，大家乱开，早晚撞车。有了规则，虽然要等红灯，但整体效率反而更高。

4.2 Git Flow：适合复杂嵌入式项目

Git Flow 是我在大型嵌入式项目中用得最多的策略。它分支多，规则严，但对付复杂场景特别好使。

4.2.1 核心分支结构

分支类型	命名示例	用途
master	master	只存放发布版本，每个提交都对应一个生产版本
develop	develop	日常开发的主分支，所有功能分支都从这里拉出
feature	feature/usb-stack	开发新功能，完成后合并回 develop
release	release/v2.1.0	发布前的准备分支，只做 bug 修复和文档更新
hotfix	hotfix/crc-bug	紧急修复生产环境的问题，修复后同时合并到 master 和 develop

4.2.2 嵌入式场景实战

我在做一个车载 MCU 项目时，就严格用了 Git Flow。当时的情况是这样的：

• feature 分支：每个新功能（比如 CAN 总线驱动、OTA 升级模块）都在独立分支上开发。互不干扰，想怎么改都行。
• release 分支：功能开发完，合并到 develop 后，拉出 release/v2.1.0。这个分支只修 bug，不加新功能。测试团队就在这个分支上跑。
• hotfix 分支：有一次客户反馈设备偶发死机。我立刻从 master 拉出 hotfix/task-stack-overflow，定位到是任务栈分配不足。修完合并回 master 和 develop，整个过程不到 4 小时。

4.3 GitHub Flow：轻量级选择

GitHub Flow 就简单多了。它只有 master 一个长期分支，所有开发都在 feature 分支上完成，然后通过 Pull Request 合并。

4.3.1 工作流程

1. 从 master 拉出 feature 分支
2. 在 feature 分支上开发、提交
3. 发起 Pull Request，进行代码审查
4. 审查通过后合并到 master
5. 立即部署或发布

4.3.2 适合什么场景？

说实话，GitHub Flow 更适合互联网项目那种「随时发布」的模式。嵌入式开发中，我只有在做原型验证或小工具项目时才用它。

为什么？因为嵌入式固件很少能做到「随时发布」。你想想看，固件发布前要经过编译、烧录、硬件测试、环境测试，一套流程下来少说半天。GitHub Flow 那种「合并即发布」的节奏，在嵌入式领域不太现实。

4.4 嵌入式场景的特殊考量

4.4.1 硬件版本分支

嵌入式开发有个特点：不同硬件版本可能对应不同的代码。比如 V1.0 板子用 STM32F103，V2.0 换成了 STM32F407。这时候我建议：

• 每个硬件版本维护一个长期分支，比如 hw/v1.0、hw/v2.0
• 公共代码放在 develop 分支，通过条件编译或抽象层处理差异
• 紧急修复时，从对应硬件分支拉 hotfix

4.4.2 固件版本号与分支对应

我个人习惯用语义化版本号（SemVer）来命名 release 分支：

release/v1.2.0    # 主版本.次版本.修订号
hotfix/v1.2.1     # 紧急修复版本

这样一看分支名，就知道这个版本是干什么的。嗯，这个习惯帮我省了不少查日志的时间。

4.5 我的推荐方案

如果你问我嵌入式项目到底该用哪个？我的回答是：看项目复杂度。

项目类型	推荐策略	原因
单芯片、单版本的小项目	GitHub Flow 简化版	分支少，管理成本低
多硬件版本、多团队协作	Git Flow	分支隔离好，版本管理清晰
既有产品维护，又有新平台开发	Git Flow + 硬件分支	能同时处理多个硬件版本

记住，分支管理的目的只有一个：让代码变更可追溯、可回滚、可并行。只要做到这三点，用什么策略都行。