1. 版本控制基础：为什么嵌入式团队需要Git？Git与SVN的核心区别
说实话，我见过太多嵌入式团队还在用U盘拷代码、用文件夹命名来管理版本。嗯，那种日子我经历过——改个bug要翻十几个备份文件，最后发现改的是旧版本。今天咱们就聊聊，为什么嵌入式团队必须拥抱Git，以及它跟SVN到底差在哪。
1.1 嵌入式开发的版本管理痛点
嵌入式开发跟纯软件不一样。你想想看，我们不光要管代码，还得管编译器版本、芯片SDK、硬件配置文件、甚至不同板子的固件。我当年在智能家居团队时，最头疼的就是「这个版本烧录到A板能跑，B板就死机」——后来发现是某个头文件被覆盖了。
嵌入式团队常见的版本管理问题：
- 多人协作冲突：两个人同时改同一个驱动文件，合并时发现改了不同行，但逻辑上互相矛盾
- 硬件依赖管理：不同硬件版本需要不同的配置宏，但没人记录哪个配置对应哪个硬件
- 二进制文件混乱：编译好的hex、bin文件散落在各个文件夹，分不清哪个是最新
- 回滚困难：发现新功能引入bug，但已经改了20个文件，没法精准回退
核心痛点：嵌入式开发中，代码只是冰山一角。工具链、库文件、硬件描述文件、测试脚本——这些都需要版本控制。没有Git，你就是在裸奔。
1.2 Git vs SVN：核心区别在哪？
很多老工程师习惯用SVN，觉得「够用就行」。但我在几个项目里对比过，差距真的很大。咱们直接看对比表：
| 对比维度 | Git | SVN |
|---|---|---|
| 架构 | 分布式，每个开发者都有完整仓库 | 集中式，所有操作依赖中央服务器 |
| 离线工作 | 完全支持，提交、查看历史、分支切换都行 | 基本不支持，大部分操作需要联网 |
| 分支管理 | 轻量级分支，创建合并成本极低 | 分支是目录拷贝，操作慢且占用空间 |
| 二进制文件 | 支持，但仓库会膨胀（需配合LFS） | 原生支持，但大文件会拖慢服务器 |
| 学习曲线 | 较陡，概念多（暂存区、rebase等） | 较平缓，概念简单 |
| 安全性 | 每个仓库都是完整备份，单点故障风险低 | 服务器挂了就全挂，依赖备份策略 |
说白了，SVN像是一个中央图书馆——所有人都去那里借书还书。Git更像是每个人家里都有完整藏书，想怎么改都行，改完了再同步。我个人习惯用Git，因为出差调试时经常没网，Git让我在高铁上也能提交代码。
1.3 为什么嵌入式团队必须用Git？
我总结了几条硬核理由：
- 离线调试是刚需：嵌入式工程师经常在产线、实验室、客户现场调试。这些地方网络不稳定甚至没网。Git让你在离线状态下也能完整工作——提交、分支、查看历史，样样都行。SVN？没网就只能干瞪眼。
- 分支策略拯救多版本维护：嵌入式产品经常要维护多个硬件版本。比如V1.0量产版、V2.0开发版、某个客户的定制版。Git的分支切换成本极低，我可以在不同分支间快速切换，对比差异。SVN的分支？创建一次要等半天。
- 代码审查与质量把控：Git配合Pull Request机制，让代码审查成为标准流程。我在团队里强制要求：任何改动必须经过PR审查才能合并。这大大减少了「改了一行，炸了整个模块」的惨剧。
- CI/CD集成：现在的嵌入式CI/CD工具（如Jenkins、GitLab CI）都原生支持Git。每次提交自动触发编译、静态检查、单元测试。SVN虽然也能集成，但体验差很多。
我的经验：曾经有个项目，团队用SVN管理一个包含RTOS、驱动、应用层的复杂固件。每次发布新版本，都要手动记录每个文件的版本号。后来迁移到Git，配合标签（tag）和发布分支，发布流程从半天缩短到10分钟。
1.4 嵌入式Git实战：避坑指南
Git虽好，但嵌入式场景下有几个坑要注意。我曾经踩过，分享给你：
- 二进制文件管理：Git对文本文件很友好，但对hex、bin、库文件等二进制文件，每次修改都会完整保存一份。仓库会迅速膨胀。解决方案是使用Git LFS（Large File Storage），把大文件托管到外部存储。
- 不要提交编译产物：很多新手会把编译生成的.o、.hex、.bin文件也提交到仓库。这是大忌！这些文件每次编译都会变，导致仓库混乱。正确做法是只提交源码和构建脚本，用.gitignore过滤掉编译产物。
- 子模块（Submodule）要慎用：嵌入式项目经常依赖第三方库（如FreeRTOS、LwIP）。用子模块管理依赖很方便，但更新时容易出问题。我建议用Git Subtree或者直接复制依赖源码到仓库，管理更简单。
- 分支命名规范：团队里一定要统一分支命名。比如feature/xxx、bugfix/xxx、release/xxx。不然过两个月你自己都看不懂哪个分支是干嘛的。
我曾经踩过的坑：有次团队用Git管理一个包含大量图片资源的嵌入式UI项目。大家都没用LFS，结果仓库从200MB膨胀到2GB，clone一次要半小时。后来花了整整两天清理历史记录，才把仓库瘦身回来。记住：从一开始就用LFS管理大文件！
1.5 从SVN迁移到Git：我的建议
如果你团队还在用SVN，别急着全盘迁移。我建议分三步走：
- 先小范围试点：选一个非核心项目，让几个愿意尝鲜的同事用Git管理。跑一两个迭代，看看效果。
- 培训与规范：Git的学习曲线确实比SVN陡。花时间做培训，制定团队规范——比如分支策略、提交信息格式、代码审查流程。
- 逐步迁移：用git-svn工具可以把SVN仓库完整迁移到Git，保留所有历史记录。迁移后保留SVN只读访问一段时间，方便大家适应。
说实话，迁移过程会有点痛苦。但一旦团队习惯了Git的分布式工作流，你会发现协作效率提升不止一个档次。我带的团队从SVN迁移到Git后，代码冲突减少了60%，发布周期缩短了40%。
嗯，版本控制基础就聊到这。下一章咱们深入讲讲Git的分支策略——怎么在嵌入式项目中用好feature branch、release branch、hotfix branch，让多版本维护不再头疼。