版本控制基础：Git核心概念、Git工作流、嵌入式项目的.gitignore配置、大型二进制文件管理
聊到嵌入式CI/CD，版本控制是绕不开的基石。我见过太多团队，代码管理混乱，合并冲突不断，最后连哪个版本能跑起来都搞不清楚。说白了，Git就是你的时间机器和协作枢纽。这一章，我把嵌入式开发中Git的实战要点掰开揉碎讲清楚。
Git核心概念：你只需要记住这几个
很多人学Git被一堆概念吓住了。其实核心就三个：工作区、暂存区、版本库。你想想看，工作区就是你写代码的目录，暂存区是准备提交的缓冲区，版本库就是历史记录仓库。
我个人习惯把暂存区理解成「购物车」。你从货架上（工作区）挑东西，放到购物车（暂存区），最后去收银台结账（commit）。
嵌入式开发中特别要注意：每次commit应该是一个逻辑完整的改动。不要攒了一周的代码一次性提交，那样出了问题根本没法回滚。
还有一个概念叫HEAD指针。它指向你当前所在的提交。切换分支，本质上就是移动HEAD指针。我在项目中遇到过有人直接修改了HEAD指向的提交，结果导致分支历史混乱——嗯，新手千万别这么干。
Git工作流：GitFlow vs Trunk-Based
工作流的选择直接影响团队协作效率。嵌入式项目因为涉及硬件依赖和固件发布，选对工作流能省一半的麻烦。
GitFlow：适合正式发布周期长的项目
GitFlow有5个分支：master、develop、feature、release、hotfix。结构清晰，但分支多，合并频繁。
| 分支类型 | 用途 | 嵌入式场景举例 |
|---|---|---|
| master | 生产就绪代码 | 已通过硬件测试的固件 |
| develop | 日常开发主线 | 集成新功能的固件 |
| feature | 新功能开发 | 添加某个传感器驱动 |
| release | 发布前准备 | 版本号更新、最终测试 |
| hotfix | 紧急修复 | 现场发现的严重bug |
我曾经在一个车载项目里用GitFlow。硬件版本迭代慢，固件发布周期两个月一次，GitFlow的release分支正好用来做回归测试。但如果你团队小、发布频繁，GitFlow会让你累死——合并分支的时间比写代码还长。
Trunk-Based：适合快速迭代
Trunk-Based只有一条主干分支，所有开发者直接往主干提交。通过短生命周期特性分支（通常不超过一天）和频繁集成来保证质量。
我的建议：如果你的嵌入式项目是IoT设备，需要每周甚至每天发布OTA更新，用Trunk-Based。配合特性开关（feature toggle），可以控制哪些功能上线。
为什么Trunk-Based在嵌入式里越来越流行？因为CI/CD要求频繁集成。你想想看，如果每个人都在自己的feature分支上开发两周，合并时发现和硬件接口不兼容——那画面太美我不敢看。
嵌入式项目的.gitignore配置
这个文件看似简单，但配置错了会出大问题。我见过有人把整个build目录提交到仓库，结果仓库体积暴涨到几个GB。
嵌入式项目需要忽略的典型文件：
# 编译产物
*.o
*.elf
*.hex
*.bin
*.map
build/
Debug/
Release/
# IDE配置（不同人用不同IDE）
.idea/
.vscode/
*.uvoptx
*.uvguix
*.ewp
*.ewd
# 工具链生成文件
*.crf
*.d
*.dep
*.lst
# 操作系统文件
.DS_Store
Thumbs.db
# 敏感信息
*.key
*.pem
config.local.h注意：不要一股脑把所有生成文件都忽略。比如链接脚本.ld文件、启动文件startup_*.s，这些是项目的一部分，应该保留在仓库里。
我曾经接手一个项目，发现.gitignore里把所有的.s文件都忽略了。结果换了芯片型号，启动文件找不到了——折腾了两天才从备份里翻出来。
大型二进制文件管理：Git LFS
嵌入式项目里，二进制文件是逃不掉的。固件镜像、芯片数据手册、PCB设计文件、测试用的音视频素材……这些文件动辄几十MB甚至GB级别。Git本身对二进制文件处理很差，每次提交都会完整复制一份，仓库体积膨胀得飞快。
Git LFS（Large File Storage） 就是干这个的。它把大文件替换成指针文件，真正的文件内容存储在远程服务器上。本地只保留指针，拉取时按需下载。
安装和配置
# 安装LFS
git lfs install
# 指定要跟踪的文件类型
git lfs track "*.bin"
git lfs track "*.hex"
git lfs track "*.pdf"
git lfs track "*.mp4"
# 提交跟踪配置
git add .gitattributes
git commit -m "配置LFS跟踪规则"嵌入式项目中的LFS策略
| 文件类型 | 建议策略 | 原因 |
|---|---|---|
| 固件镜像(.bin/.hex) | 必须用LFS | 体积大，版本多 |
| 芯片数据手册(.pdf) | 建议用LFS | 只读文件，但需要版本关联 |
| 测试音视频 | 必须用LFS | 动辄几百MB |
| 编译工具链 | 不要用Git管理 | 用包管理器或Docker |
避坑指南：我曾经把编译好的工具链（1.2GB）直接提交到Git仓库，结果所有开发者拉取代码都要等半小时。后来改用Docker镜像管理工具链，仓库体积瞬间降到200MB。
LFS的注意事项
第一，LFS有存储配额限制。GitHub免费版只有1GB存储和1GB带宽/月。如果团队大、文件多，建议自建Git LFS服务器或用商业方案。
第二，LFS文件不能做diff。你没法看到两个版本的.bin文件有什么区别。所以，源代码和配置文件一定要用文本格式管理，只有最终产物才用LFS。
第三，迁移已有仓库到LFS要小心。如果仓库里已经有大文件历史，需要用git lfs migrate命令重写历史。这个操作会改变commit hash，需要所有开发者重新克隆。
# 迁移已有仓库中的大文件
git lfs migrate import --include="*.bin,*.hex" --everything警告：迁移操作不可逆！执行前一定要备份仓库。我见过有人迁移到一半网络断了，结果仓库损坏，最后从备份恢复的。
好了，版本控制这块就聊到这儿。下一章我们讲持续集成，到时候你会看到，没有好的版本控制，CI/CD就是空中楼阁。
公众号:蓝海资料掘金营，微信deep3321