1. 版本管理基础：为什么嵌入式项目需要版本管理？Git vs SVN 对比，嵌入式场景下的选择。
说实话，我见过太多嵌入式团队还在用「复制粘贴+日期命名」的方式管理代码。
什么「main_final_v3_改李工_勿动.c」—— 你想想看，这种命名方式，三个月后你自己都分不清哪个是哪个。我在2015年刚带项目时，就吃过这个亏。一个固件版本搞混了，产线烧录错了，直接报废了200多块板子。从那以后，版本管理就成了我团队的红线。
为什么嵌入式项目必须上版本管理？
很多人觉得版本管理是「软件工程师的事」，嵌入式嘛，硬件定了代码就定了。其实大错特错。嵌入式项目有几个特点，决定了它比纯软件更需要版本管理：
- 硬件依赖性强：同一个代码，换一颗MCU、改一个引脚，可能就要分支管理。没有版本管理，你根本不知道哪个版本对应哪个硬件。
- 固件迭代频繁：从原型验证到量产，中间可能有几十个版本。每个版本都要能回溯，否则出了问题你连「之前能跑的那个版本」都找不回来。
- 多人协作冲突：驱动工程师改底层，应用工程师改逻辑，两个人改同一个文件是家常便饭。没有版本管理，覆盖代码就是分分钟的事。
- 合规与追溯：医疗、汽车、工控行业，审计要求你拿出每个版本的变更记录。没有版本管理，你拿什么给客户看？
核心观点：版本管理不是「锦上添花」，而是嵌入式开发的「安全带」。没有它，你就是在裸奔。
Git vs SVN：到底选哪个？
这个问题我几乎每次培训都会被问到。我的回答很简单：2024年了，新项目无脑选Git。但为什么？咱们得讲清楚。
| 对比维度 | Git | SVN |
|---|---|---|
| 架构 | 分布式，每个开发者本地有完整仓库 | 集中式，所有操作依赖中央服务器 |
| 离线工作 | 完全支持，提交、分支、查看历史均可离线 | 不支持，大部分操作需要联网 |
| 分支管理 | 轻量级分支，创建合并成本极低 | 分支本质是目录拷贝，成本高 |
| 性能 | 本地操作极快，大仓库性能好 | 大文件多时，提交和更新较慢 |
| 学习曲线 | 较陡，概念多（暂存区、rebase等） | 较平缓，上手快 |
| 二进制文件 | 原生支持一般，需配合LFS | 原生支持较好，适合管理库文件 |
我的建议：如果你团队里有人还在用SVN，别急着全盘否定。老项目维护可以继续用SVN，但新项目、新团队，一定要上Git。为什么？因为生态。现在GitHub、GitLab、Gitee，所有CI/CD工具都优先支持Git。你学Git，学的是整个现代开发流程。
嵌入式场景下的特殊考量
嗯，这里要注意。嵌入式项目跟纯软件项目不一样，有几个特殊点会影响你的版本管理策略：
1. 二进制文件管理
嵌入式项目里，编译器、库文件、芯片SDK、PDF文档、原理图……这些二进制文件怎么管？Git原生对二进制文件支持不好，每次修改都会把整个文件存一遍，仓库会迅速膨胀。
我曾经见过一个项目，因为把几十MB的编译器压缩包直接丢进Git，仓库半年就涨到5GB。后来我们用了Git LFS（Large File Storage），把二进制文件单独托管，才解决了这个问题。
2. 分支策略要适配硬件
纯软件项目可以「主干开发，分支发布」。但嵌入式项目，硬件版本不同，代码可能完全不兼容。我习惯的做法是：
- 硬件版本分支：每个硬件版本（如V1.0、V2.0）建一个长期分支
- 功能分支：在对应硬件分支上拉功能分支开发
- 标签管理：每个固件发布版本打标签，标签名包含硬件版本+固件版本（如 HW_V2.0_FW_1.3.2）
避坑指南：千万不要把所有硬件版本的代码混在一个分支里。我见过有人用宏定义区分硬件版本，结果代码里全是 #ifdef HW_V1 / #ifdef HW_V2，维护起来简直是噩梦。分支隔离，比宏隔离要干净得多。
3. 提交粒度要适中
嵌入式开发有个特点：改一行代码，可能要编译、烧录、测试，周期很长。所以提交粒度不能太细，也不能太粗。
我个人习惯：
- 功能完整时提交：一个功能模块调试通过后，做一次提交
- 提交信息要写清楚：不要写「fix bug」这种废话。要写「修复UART2在115200波特率下丢数据的bug，原因是FIFO阈值设置错误」
- 编译通过的代码才能提交：这是底线。不能提交的代码，用stash暂存
Git在嵌入式项目中的基本工作流
说了这么多，咱们看看实际怎么用。下面是我团队的标准工作流：
# 1. 克隆仓库
git clone git@github.com:your-company/your-firmware.git
# 2. 创建功能分支（基于当前硬件版本分支）
git checkout -b feature/add-temp-sensor HW_V2.0
# 3. 开发、编译、测试...
# 4. 暂存修改
git add .
# 5. 提交（写清楚信息）
git commit -m "feat: 添加温度传感器驱动，支持DS18B20，单总线模式"
# 6. 拉取最新代码，解决冲突
git pull origin HW_V2.0 --rebase
# 7. 推送分支
git push origin feature/add-temp-sensor
# 8. 创建Pull Request，代码审查后合并到HW_V2.0分支
# 9. 发布时打标签
git tag -a HW_V2.0_FW_1.3.2 -m "量产版本，修复了看门狗复位问题"
git push origin HW_V2.0_FW_1.3.2小技巧：我习惯在提交信息里加上「类型前缀」，比如 feat（新功能）、fix（修复）、docs（文档）、refactor（重构）。这样后期看git log，一眼就能知道每次提交的性质。这个习惯我从2018年坚持到现在，真的很好用。
总结一下
版本管理这件事，说白了就是「花小钱办大事」。你花一天时间搭好Git仓库、定好分支策略，后面能省下无数个加班的夜晚。
我个人建议：
- 新项目用Git，老项目如果SVN用得顺手也别强求
- 二进制文件用Git LFS管理
- 分支策略要跟硬件版本绑定
- 提交信息写清楚，别偷懒
下一章，咱们聊聊具体的Git操作——怎么初始化仓库、怎么配置.gitignore、怎么处理嵌入式项目里那些烦人的编译产物。到时候见。