版本控制选型：Git vs SVN，在嵌入式场景下的选择策略
说到版本控制，很多嵌入式工程师第一反应就是「Git 啊，还用选吗？」。但说实话，我在嵌入式这行摸爬滚打十几年，见过太多团队在版本控制工具上栽跟头。Git 和 SVN 各有各的脾气，选错了，后面 CI/CD 流水线跑起来就是噩梦。
今天我就跟你聊聊，在嵌入式场景下，这两个工具到底该怎么选。
先说说 SVN 的老底
SVN 是集中式版本控制的老大哥。它的核心思想很简单：所有代码都放在中央服务器上，你要改代码，先 checkout，改完再 commit。听起来挺顺的，对吧？
我在 2010 年左右接手过一个车载项目，团队用的就是 SVN。那时候觉得挺稳的，毕竟中央服务器一锁，谁改了啥一目了然。但后来问题来了——嵌入式项目里，二进制文件特别多。固件镜像、库文件、编译中间产物，动不动就几百兆。SVN 处理这些大文件还行，但一旦分支多了，服务器磁盘空间蹭蹭往上涨。
SVN 在嵌入式场景下的优势：
- 大文件友好：SVN 对二进制文件的存储和传输效率比 Git 高。Git 每次 clone 都要拉全量历史，SVN 只拉最新版本。
- 权限控制精细：可以精确到目录级别。比如「这个驱动库只有硬件组能改」——这在合规性要求高的项目里很实用。
- 学习曲线平缓：团队成员不需要理解「暂存区」「rebase」「cherry-pick」这些概念。checkout、commit、update，三招走天下。
但 SVN 的坑也不少：
- 离线等于废掉：没网络？那你连看个历史记录都费劲。嵌入式工程师经常出差、下产线、去客户现场调试，网络环境一言难尽。
- 分支管理笨重：SVN 的分支本质上是目录拷贝。分支一多，服务器上全是文件夹，合并时冲突处理让人头大。
- CI/CD 集成麻烦：现在主流的 CI 工具对 Git 的支持是原生级别的，对 SVN 嘛……总感觉是后妈养的。
Git 到底强在哪？
Git 是分布式版本控制，每个开发者本地都有完整的仓库副本。这意味着什么？你可以在飞机上、在高铁上、在客户机房里，没有任何网络的情况下，照样 commit、branch、merge。等有网了再 push 上去。
我记得有一次在产线调试，现场网络断了，我靠 Git 本地分支做了三个版本的实验性修改，最后挑了一个最稳的 push 回去。要是用 SVN，那天估计就白干了。
Git 在嵌入式场景下的优势：
- 离线工作能力：这是杀手锏。嵌入式开发环境经常受限，Git 的本地仓库让你在任何地方都能干活。
- 分支轻量且强大：Git 的分支只是一个指针，创建和切换几乎零成本。你可以为每个特性、每个 bugfix、每个实验性改动都开一个分支。
- 社区生态成熟：GitHub、GitLab、Gitee……几乎所有 CI/CD 工具都优先支持 Git。Actions、Jenkins Pipeline、GitLab CI，跟 Git 配合得天衣无缝。
- 代码审查方便：Pull Request / Merge Request 机制，让代码审查成为团队协作的标准流程。
但 Git 也不是万能药：
- 二进制文件是硬伤：Git 对文本文件很友好，但对二进制文件（.bin、.hex、.elf、库文件）的存储效率极低。每次 commit 都会保存完整副本，仓库体积会迅速膨胀。我见过一个项目，因为把编译产物也 commit 了，仓库从 200MB 涨到 8GB。
- 学习曲线陡峭：Git 的概念太多。暂存区、HEAD、rebase、cherry-pick、detached HEAD……新手很容易搞混。团队里如果有人乱用 git push --force，那酸爽……
- 大仓库性能下降：当仓库历史超过几万次 commit，或者包含大量大文件时，git log、git status 这些基本操作都会变慢。
嵌入式场景下的选择策略
好了，两边都分析完了。那到底怎么选？我个人的经验是：没有银弹，看项目类型和团队情况。
我整理了一个决策表格，你可以对照着看：
| 项目特征 | 推荐工具 | 理由 |
|---|---|---|
| 纯固件开发，代码为主，少量二进制 | Git | 分支灵活，离线可用，CI/CD 集成好 |
| 包含大量库文件、镜像、工具链 | SVN + Git LFS | SVN 处理大文件好，Git LFS 可以弥补 Git 的短板 |
| 团队分散，网络不稳定 | Git | 离线工作能力是刚需 |
| 合规性要求高，需要精细权限控制 | SVN | 目录级权限控制成熟 |
| 团队新手多，不想折腾 | SVN | 学习成本低，不容易出乱子 |
| 需要频繁分支合并、特性开发 | Git | 分支管理能力碾压 SVN |
我的实战建议
如果你问我个人倾向，我现在的项目基本都用 Git。但我会搭配几个关键策略：
- 用 Git LFS 管理大文件：Git LFS 会把大文件用指针替换，实际内容存到远程服务器。这样仓库体积不会爆炸。我在一个物联网项目中，把固件镜像和测试数据都通过 LFS 管理，仓库从 5GB 降到了 200MB。
- 严格控制 commit 内容：编译产物、临时文件、IDE 配置，统统加到 .gitignore 里。我曾经见过有人把整个 build 目录都 commit 了，那场面……
- 建立分支策略：推荐 Git Flow 或者 Trunk-Based Development。小团队用 Trunk-Based 更简单，大团队用 Git Flow 更规范。
- 做好培训：Git 再强大，团队不会用也是白搭。花半天时间给团队讲清楚 rebase 和 merge 的区别，比后面擦屁股省事得多。
避坑指南：
我曾经在一个项目里，团队用 Git 管理一个包含 500 多个 .hex 文件的仓库。每次 git clone 要等 20 分钟，git status 要卡 10 秒。后来我强制把所有二进制文件迁移到 Git LFS，速度直接起飞。所以记住：Git 不是用来存二进制文件的。
最后说两句
其实 Git 和 SVN 没有绝对的好坏。我见过用 SVN 跑得飞快的团队，也见过用 Git 搞得一团糟的团队。工具只是工具，关键看你怎么用。
但如果你问我未来的趋势——Git 肯定是主流。SVN 在维护老项目、合规性要求高的场景下还有一席之地，但新项目我建议直接上 Git。配合 Git LFS 和好的分支策略，嵌入式场景完全够用。
嗯，版本控制选型就聊到这儿。下一章我们聊聊 CI/CD 工具链的选型，那才是真正头疼的地方。