Git核心概念在模型管理中的应用

说实话，很多做嵌入式AI的工程师，一开始都觉得Git是软件工程师的事。我以前也这么想——直到有一次，我花了两周调优的模型，被同事不小心覆盖了。嗯，从那以后，我再也不敢把模型文件当“普通文件”来管理了。

这一节，我们不讲那些花哨的Git命令。我就从模型管理的实际场景出发，带你看看仓库、提交、分支、标签这四个核心概念，到底怎么用在STM32Cube AI的项目里。

仓库：你的模型“保险箱”

仓库说白了，就是存放你所有模型文件的地方。但要注意，不是把整个文件夹往那一扔就完事。

我个人习惯，每个模型项目单独建一个仓库。比如：

my_ai_project/
├── .git/
├── models/
│   ├── v1.0_float32.tflite
│   ├── v1.1_quantized.tflite
│   └── v2.0_optimized.tflite
├── datasets/
├── scripts/
└── README.md

这里有个坑——数据集不要直接放仓库里。我在项目中吃过这个亏，一个数据集几个G，每次clone都像在下载电影。后来我改用Git LFS（大文件存储）或者干脆只放数据集的下载链接。

提交：给模型拍“快照”

提交就是把你当前的工作状态保存下来。但很多人提交得太随意，比如“update model”、“fix bug”这种信息，过两周你自己都看不懂。

我总结了一套模型提交的“黄金法则”：

1. 每次提交只做一件事——要么改模型结构，要么调超参数，别混在一起
2. 提交信息要包含关键指标——比如准确率、模型大小、推理时间
3. 大模型文件用Git LFS——普通Git处理不了几百MB的模型文件

举个例子，好的提交信息长这样：

feat: 添加MobileNetV2量化模型

- 模型大小: 从12.3MB降到3.1MB
- 准确率: 92.1% (下降0.3%)
- 推理时间: 从45ms降到12ms (STM32F746)
- 量化方式: 全整数量化(int8)

你看，这样的提交信息，三个月后回来翻，一眼就知道当时发生了什么。

分支：并行实验的“平行宇宙”

分支是Git里最强大的功能之一，尤其在模型迭代中。你可以同时尝试不同的模型结构、不同的量化策略，互不干扰。

我常用的分支策略是这样的：

分支名称	用途	说明
main	稳定版本	只有通过测试的模型才能合并到这里
develop	开发版本	日常实验的集散地
feature/xxx	新特性实验	比如 feature/mobilenetv3
experiment/xxx	临时实验	用完就删，比如 experiment/lr_0.001
bugfix/xxx	修复问题	比如 bugfix/memory_leak

我曾经在一个项目里，同时开了5个分支，分别尝试不同的量化策略。最后发现，experiment/int8_per_channel这个分支的效果最好，直接合并到main分支，其他分支全部删除。干净利落。

标签：模型版本的“里程碑”

标签和分支不同，标签是只读的，一旦打上就不能修改。这正好用来标记模型的正式版本。

我习惯用语义化版本号：

v1.0.0  # 第一个正式版本
v1.1.0  # 增加了新功能（比如新的量化方式）
v1.1.1  # 修复了bug（比如推理时内存溢出）
v2.0.0  # 重大更新（比如换了全新的模型结构）

打标签的时候，我还会附上详细的版本说明：

git tag -a v1.1.0 -m "版本 v1.1.0

- 新增: 支持STM32F4系列
- 优化: 推理速度提升20%
- 修复: 输入图像尺寸校验问题
- 模型: quantized_mobilenet_v2.tflite
- 准确率: 91.8% (测试集)"

这样，每次发布新版本，都对应一个清晰的标签。客户或者测试人员要哪个版本，直接checkout对应的标签就行。

核心逻辑：一张图看懂

下面这张图，是我自己总结的Git在模型管理中的核心流程。你看一遍，应该就能明白这几个概念怎么配合了。

实战中的避坑指南

最后，分享几个我在实际项目中踩过的坑：

• 不要用Git管理二进制模型文件——除非你用Git LFS。普通Git会把每个版本都存一份完整副本，仓库会变得巨大无比
• 提交前先检查.gitignore——把数据集、日志文件、临时文件都排除掉。我曾经不小心把10G的训练日志提交了，差点被同事打死
• 分支命名要有规律——我见过有人用“test1”、“test2”、“final”、“final_v2”这种名字，三个月后他自己都分不清
• 标签一定要打在有意义的提交上——不要随便打个标签，那会让版本管理变得混乱

嗯，Git的这些概念，说白了就是帮你把模型迭代的过程管起来。刚开始可能会觉得麻烦，但等你真正遇到“模型回退”、“版本对比”、“多人协作”这些场景时，你就会发现——这些功夫，花得值。