1. 课程导入
嵌入式开发，说白了就是软硬结合的艺术。我见过太多团队，代码东一版西一版，最后连哪个版本能跑都搞不清楚。版本控制不是可选项，是生存工具。
1.1 嵌入式项目的特殊挑战
嵌入式项目跟纯软件项目不一样。你想想看，代码最终要烧到芯片里，出了问题可不是改个bug那么简单——硬件改版、产线召回，成本高得吓人。
嵌入式开发的核心痛点：
- 硬件依赖：代码跟特定MCU、外设、板级配置强绑定
- 多工具链：编译器、链接脚本、烧录工具、调试器，版本一乱全完蛋
- 二进制产物：.hex、.bin、.elf 文件，谁改了什么根本看不出来
- 团队协作：驱动工程师、应用工程师、硬件工程师，各改各的
我记得有一次，团队里有人改了I2C驱动，没通知任何人。结果硬件测试那边折腾了两天，最后发现是驱动版本不对。嗯，从那以后，版本控制就成了铁规矩。
1.2 Git vs SVN：嵌入式场景怎么选？
这个问题我几乎每次培训都会被问到。直接说结论：新项目选Git，老项目如果已经用SVN跑顺了，别硬换。
| 对比维度 | Git | SVN |
|---|---|---|
| 架构 | 分布式，本地完整仓库 | 集中式，依赖服务器 |
| 离线工作 | 完全支持，飞机上也能提交 | 不行，没网就废了 |
| 分支管理 | 轻量分支，随便建随便删 | 分支就是目录拷贝，又慢又占空间 |
| 二进制文件 | 存diff效率低，大文件要配LFS | 原生支持，对大文件友好 |
| 学习曲线 | 陡峭，概念多 | 平缓，容易上手 |
| 嵌入式适用性 | 适合代码频繁迭代、多分支开发 | 适合管理固件发布、二进制归档 |
我的建议：如果团队小于10人，项目以代码开发为主，果断上Git。如果项目里大量第三方库、二进制驱动、硬件描述文件，SVN的集中管理反而更省心。
1.3 嵌入式开发中的典型痛点
做嵌入式版本控制，有几个坑我踩过，你千万别再踩。
痛点一：二进制文件谁来管？
编译出来的.hex、.bin，还有第三方库的.lib、.a文件，Git处理起来很吃力。每次改一点点，整个文件重新存一遍，仓库体积蹭蹭涨。
避坑指南：我曾经把一个带WIFI固件的项目直接push到Git仓库，结果仓库飙到2GB。后来老老实实配了Git LFS，把二进制文件托管到外部存储，才救回来。
痛点二：工具链版本不一致
你用的ARM GCC 10.3，同事用的9.2，编译出来的代码行为可能不一样。这种问题版本控制管不了，但你可以把工具链版本写进README，或者用Docker/DevContainer锁定环境。
痛点三：分支策略混乱
嵌入式项目经常要维护多个硬件版本：V1.0板、V2.0板、量产版、测试版。分支怎么命名？怎么合并？我见过有人直接在master上改，改完就忘，最后谁也分不清哪个是哪个。
推荐的分支模型：
- master：只放经过硬件测试、可以量产的版本
- develop：日常开发集成
- feature/xxx：每个新功能一个分支
- release/vX.Y：发布候选，做最终验证
- hotfix/xxx：紧急修复，直接从master拉
1.4 嵌入式版本控制的核心逻辑
说了这么多，其实核心就一句话：版本控制不是存代码，是管变更。谁、在什么时候、为什么改、改了什么，这些信息比代码本身更值钱。
下面这张图，是我自己总结的嵌入式版本控制知识体系，你看一眼就能明白整体脉络。
1.5 从今天开始，你该做什么？
如果你是第一次给嵌入式项目上版本控制，别想太复杂。三步走：
- 先把代码放进仓库——Git init，commit，push，就这么简单
- 写一个.gitignore——把编译产物、IDE配置、临时文件都屏蔽掉
- 定一个分支命名规则——哪怕只是口头约定，也比没有强
一个小技巧：我习惯在每次提交时，把编译通过的.hex文件也归档一份，命名带上commit hash。这样万一哪天要回滚到某个固件版本，直接找文件就行，不用重新编译。
版本控制这件事，越早做越省心。别等到项目炸了再后悔——我替你试过了，那滋味不好受。