2. 版本控制基础：Git在嵌入式项目中的应用、Git Flow工作流、大型二进制文件管理（Git LFS）
嵌入式开发中的版本控制，说实话，跟纯软件项目还真不太一样。我最早带团队做嵌入式项目时，就吃过不少亏——代码和硬件配置混在一起、固件镜像动不动几百兆、多人协作时合并冲突搞得鸡飞狗跳。后来慢慢摸索出一套适合嵌入式场景的Git用法，今天跟你聊聊。
2.1 Git在嵌入式项目中的特殊挑战
嵌入式项目跟普通软件项目比，有几个明显的不同点：
- 硬件依赖性强：代码往往跟特定板卡、芯片绑定，不同硬件分支的管理是个麻烦事
- 二进制文件多：固件镜像、库文件、工具链、文档PDF，这些都不是文本文件，Git没法做差异比较
- 多人协作复杂：硬件工程师、嵌入式软件工程师、测试工程师，大家用的工具链都不一样
- 版本追溯要求高：出了问题要能精确回退到某个固件版本，甚至要能复现当时的编译环境
我记得有一次，项目组急着发布一个固件版本，结果发现有人把编译好的.bin文件直接提交到了仓库里。仓库瞬间膨胀到2个多G，克隆一次要半小时。嗯，从那以后我就立了规矩——二进制文件必须用Git LFS管理。
2.2 Git Flow工作流：嵌入式项目的适配方案
Git Flow是个经典的分支模型，但直接套用到嵌入式项目里，其实有点水土不服。我个人的习惯是做一些调整：
嵌入式项目Git Flow核心分支：
- master：只存放经过完整测试、可以发布的固件版本。每个commit都对应一个可烧录的镜像
- develop：日常开发的主分支。所有新功能、bug修复都从这里拉分支
- feature/*：功能开发分支。比如feature/add-sensor-driver、feature/optimize-boot-time
- release/*：发布准备分支。在这个分支上做最后的回归测试、版本号更新、文档整理
- hotfix/*：紧急修复分支。线上固件出问题了，直接从master拉分支修
你可能会问：为什么嵌入式项目要这么严格？说白了，嵌入式设备一旦部署出去，升级固件的成本很高。不像App可以随时推送更新，很多嵌入式设备是通过OTA或者现场烧录来升级的，出错了就是真金白银的损失。
我在一个智能家居项目中就遇到过这种情况：开发人员直接在master上改代码，结果把某个传感器的初始化顺序搞反了，导致一批设备出厂后无法正常唤醒。那次教训之后，我们强制要求所有修改必须走feature分支，合并前必须经过代码审查和硬件测试。
2.3 嵌入式项目中的分支策略实战
给你看一个我常用的分支操作流程：
# 1. 从develop拉取新功能分支
git checkout develop
git pull
git checkout -b feature/add-wifi-manager
# 2. 开发过程中，定期合并develop的更新
git fetch origin
git rebase origin/develop
# 3. 功能开发完成，合并回develop
git checkout develop
git merge --no-ff feature/add-wifi-manager
# 4. 准备发布时，创建release分支
git checkout -b release/v1.2.0
# 在这里更新版本号、编译固件、做回归测试
# 5. 测试通过后，合并到master和develop
git checkout master
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git checkout develop
git merge --no-ff release/v1.2.0
# 6. 紧急修复
git checkout master
git checkout -b hotfix/fix-crash-on-boot
# 修复完成后
git checkout master
git merge --no-ff hotfix/fix-crash-on-boot
git tag -a v1.2.1 -m "Hotfix: fix crash on boot"
git checkout develop
git merge --no-ff hotfix/fix-crash-on-boot小技巧：嵌入式项目建议每次合并都使用--no-ff参数。这样能保留分支的历史信息，方便以后追溯。我曾经靠这个参数，在三个月后快速定位了一个bug是在哪个功能分支引入的。
2.4 大型二进制文件管理：Git LFS实战
嵌入式项目里，二进制文件是绕不开的痛。固件镜像、芯片数据手册、工具链安装包、测试用的音视频文件……这些文件动辄几十上百兆，直接放Git仓库里，团队协作会变得非常痛苦。
Git LFS（Large File Storage）就是用来解决这个问题的。它的原理很简单：把大文件的实际内容存储在远程服务器上，仓库里只保存一个指向该文件的指针。这样克隆仓库时，只会下载指针文件，真正的大文件按需下载。
2.4.1 安装和配置Git LFS
# 安装Git LFS（以Ubuntu为例）
sudo apt-get install git-lfs
# 初始化Git LFS
git lfs install
# 在仓库中指定要跟踪的文件类型
git lfs track "*.bin"
git lfs track "*.hex"
git lfs track "*.elf"
git lfs track "*.pdf"
git lfs track "*.zip"
# 查看跟踪规则
git lfs track
# 提交跟踪规则文件
git add .gitattributes
git commit -m "Configure Git LFS for binary files"注意：一定要在第一次提交大文件之前就配置好Git LFS。如果已经提交了大文件到仓库，再配置LFS是没法自动转换的。我曾经犯过这个错，最后不得不重写仓库历史，折腾了大半天。
2.4.2 Git LFS的日常使用
配置好之后，日常使用跟普通Git几乎一样：
# 添加大文件（会自动使用LFS存储）
git add firmware_v1.2.0.bin
# 提交和推送
git commit -m "Add firmware binary v1.2.0"
git push origin main
# 查看LFS文件状态
git lfs ls-files
# 拉取LFS文件
git lfs pull
# 查看LFS使用情况
git lfs status2.4.3 嵌入式项目中的LFS最佳实践
| 文件类型 | 建议策略 | 说明 |
|---|---|---|
| 固件镜像（.bin, .hex, .elf） | 必须使用LFS | 每个版本都要保留，方便回退和对比 |
| 芯片数据手册（.pdf） | 建议使用LFS | 文档更新不频繁，但体积大 |
| 工具链安装包（.tar.gz, .zip） | 建议使用LFS | 最好统一管理，避免每个人下载不同版本 |
| 测试数据（音视频、日志） | 按需使用LFS | 如果体积超过10MB，建议用LFS |
| 编译中间文件（.o, .d） | 不要提交 | 添加到.gitignore，每次重新编译 |
核心原则：只提交源代码和必要的构建脚本。所有编译产物、临时文件、个人配置文件都不要进仓库。我在项目中见过有人把整个编译输出目录都提交了，仓库直接变成10个G，克隆一次要半小时。
2.5 嵌入式项目中的.gitignore配置
好的.gitignore能避免很多麻烦。这是我常用的嵌入式项目.gitignore模板：
# 编译输出
build/
*.o
*.d
*.elf
*.map
*.hex
*.bin
*.lst
# IDE配置
.idea/
.vscode/
*.swp
*.swo
*~
# 工具链相关
toolchain/
gcc-arm-none-eabi*/
# 个人配置文件
*.local
*.user
*.settings
# 测试输出
test_output/
*.log
*.dump
# 文档缓存
*.aux
*.log
*.out
*.toc我的习惯：每个嵌入式项目我都会在根目录放一个README.md，里面写明项目使用的工具链版本、编译命令、烧录方法。这样新同事加入时，不用到处问人。说白了，文档也是版本控制的一部分。
2.6 避坑指南：嵌入式Git使用中的常见问题
做嵌入式开发这么多年，我踩过不少坑，挑几个典型的跟你说说：
- 不要提交编译产物：我曾经见过有人把整个build目录提交了，理由是"方便其他人直接烧录"。结果仓库越来越大，最后不得不重写历史。正确的做法是用CI/CD自动编译，或者单独维护一个固件发布仓库。
- 注意文件权限：嵌入式项目经常需要设置脚本的可执行权限。Git默认不跟踪文件权限变化，需要用git update-index --chmod=+x来手动设置。
- 小心换行符问题：Windows和Linux的换行符不同，可能导致编译错误。建议在仓库根目录放一个.gitattributes文件，统一使用LF换行符。
- 大文件提交后无法删除：即使删除了大文件，它的历史记录仍然存在于Git仓库中。如果误提交了大文件，需要用git filter-branch或BFG Repo-Cleaner来清理历史。
嗯，版本控制这块内容其实挺多的。但只要你把基础打牢了，后面用CI/CD、自动化测试都会顺畅很多。下一章我们聊聊嵌入式项目的持续集成环境搭建，到时候会用到今天讲的这些Git知识。