版本控制实战：Git Flow 在嵌入式项目中的落地，分支策略与代码Review规范
嵌入式项目的版本控制，说实话，比纯软件项目要复杂不少。你想想看，我们不光要管代码，还得管硬件配置、编译器版本、甚至烧录工具的兼容性。我见过太多团队，Git 用得挺溜，但一到嵌入式项目就乱成一锅粥。
今天我就把我在几个量产项目里踩过的坑、总结出的经验，掰开了揉碎了讲给你听。
为什么嵌入式项目需要 Git Flow？
很多人觉得 Git Flow 太重，不适合小团队。但嵌入式项目有个特点：硬件和软件强耦合。你改一行代码，可能意味着要重新烧录、重新测试硬件。如果没有清晰的分支策略，就会出现「这个版本烧进去板子不跑，那个版本又缺了某个驱动」的尴尬局面。
我个人习惯，在嵌入式项目里用简化版的 Git Flow。为什么是简化版？因为嵌入式项目通常没有「快速迭代上线」的需求，但稳定性和可追溯性是第一位的。
核心原则：嵌入式项目的分支策略，要围绕「硬件版本」和「固件版本」两个维度来设计。
分支策略：我推荐的三层结构
直接上干货。我在团队里推行的分支模型，分三层：
| 分支层级 | 分支名称 | 用途 | 生命周期 |
|---|---|---|---|
| 主分支 | main |
生产就绪的固件版本 | 永久存在 |
| 开发分支 | develop |
日常开发集成 | 永久存在 |
| 特性分支 | feature/xxx |
新功能、驱动、Bug修复 | 短期存在，合并后删除 |
| 发布分支 | release/v1.x.x |
固件发布前的最终测试 | 发布后合并到 main 和 develop |
| 热修复分支 | hotfix/xxx |
紧急修复生产问题 | 修复后合并到 main 和 develop |
嗯，这里要注意：嵌入式项目里，我强烈建议把硬件版本号也写进分支名。比如 feature/v2.1_board_adc_driver。为什么？因为同一个功能，在不同硬件版本上实现可能完全不同。我在项目中遇到过，有人把 v2.0 板子的驱动直接合进了 v3.0 的分支，结果烧进去板子直接冒烟——还好只是烧了 IO 口。
实战：嵌入式项目的 Git Flow 落地步骤
光讲理论没用，我给你一个可以直接抄的流程。
第一步：初始化仓库
别直接 git init 就完事。我建议一开始就建好 main 和 develop 分支，并且把 .gitignore 配置好。嵌入式项目里，编译产物、IDE 配置文件、硬件设计文件（如果放在一起）都要忽略。
# 嵌入式项目 .gitignore 示例
build/
*.o
*.elf
*.hex
*.bin
*.map
*.su
*.swp
.idea/
.vscode/
*.uvguix.*
*.uvoptx
第二步：特性开发流程
假设你要开发一个 I2C 驱动：
- 从
develop拉出feature/v2.1_i2c_driver - 在特性分支上开发、提交
- 开发完成后，发起 Pull Request 到
develop - 代码 Review 通过后，合并
我的习惯：特性分支的提交要「原子化」。每个提交只做一件事，比如「添加 I2C 初始化函数」和「添加 I2C 读写函数」分开提交。这样万一某个提交有问题，回滚也方便。
第三步：发布流程
当 develop 积累了一定功能，准备发布新固件时：
- 从
develop拉出release/v1.2.0 - 在这个分支上只做 Bug 修复，不添加新功能
- 测试通过后，合并到
main并打上 Tag（比如v1.2.0） - 同时合并回
develop
说白了，release 分支就是一道防火墙。我曾经有一次，直接在 develop 上修了一个 Bug 就发布了，结果那个 Bug 修好了，但新功能还没测完，导致现场升级后设备死机。从那以后，我再也不敢跳过 release 分支。
代码 Review 规范：嵌入式项目的特殊要求
代码 Review 在嵌入式项目里，比纯软件项目要严格得多。因为一个指针越界，可能直接导致硬件损坏。
我团队里的 Review 规范，分三个等级：
| 等级 | 适用场景 | Review 要求 |
|---|---|---|
| L1 快速 Review | 注释修改、日志调整、非功能性改动 | 至少 1 人 Review，24 小时内完成 |
| L2 标准 Review | 新功能、驱动开发、中等规模重构 | 至少 2 人 Review，包含 1 名硬件工程师 |
| L3 严格 Review | 中断处理、DMA、低功耗、安全相关代码 | 至少 3 人 Review，包含架构师，必须通过静态分析 |
警告：嵌入式项目里，千万不要让同一个人既写代码又 Review。我见过一个团队，驱动工程师自己写自己 Review，结果一个寄存器配置错误导致整批板子烧录后无法启动，损失了几十万。
Review 检查清单（我团队内部用的）
每次 Review，Reviewer 必须逐条检查以下内容：
- 硬件兼容性：这段代码是否依赖特定硬件版本？如果换了 MCU 型号还能跑吗？
- 资源占用：新增的代码用了多少 RAM/Flash？有没有内存泄漏风险？
- 中断安全：中断服务函数里有没有调用不可重入函数？有没有关中断时间过长？
- 错误处理：如果硬件初始化失败，代码有没有优雅降级？还是直接死循环？
- 可移植性：有没有硬编码的地址、延时、或者 Magic Number？
你想想看，如果每次 Review 都按这个清单来，能避免多少线上事故？
避坑指南：我踩过的三个大坑
最后，分享三个我亲身经历过的教训：
- 坑一：分支命名混乱。我曾经看到过
feature/123、fix_bug、test这样的分支名。三个月后，没人知道这些分支是干什么的。我的建议：分支名必须包含「功能描述+硬件版本+负责人」，比如feature/v2.1_uart_dma_john。 - 坑二：合并冲突处理不当。嵌入式项目里，头文件（
.h）的冲突特别多。我见过有人直接强制覆盖，结果把别人的引脚定义给冲掉了。正确做法：合并时一定要手动检查每个冲突，尤其是#define和结构体定义。 - 坑三：Tag 打得随意。有人打 Tag 只写
v1.0，没有 Release Notes。结果现场反馈问题，根本不知道这个版本改了啥。我现在要求：每个 Tag 必须附带 CHANGELOG，写明新增功能、修复的 Bug、以及已知问题。
好了，Git Flow 在嵌入式项目里的落地，说白了就是「规则清晰、流程严格、Review 到位」。别嫌麻烦，这些规范在项目初期可能觉得累，但到了量产维护阶段，你会感谢当初的自己。
下一章，我会讲持续集成在嵌入式项目里的实践，包括自动化编译、静态检查、以及硬件在环测试。到时候见。