版本控制基础：Git、DVC（数据版本控制）在模型和数据集管理中的应用
在Edge AI压缩实验中，模型迭代频繁、数据集版本多样、压缩前后指标对比复杂，传统的文件管理方式（如“final_model_v3_真的最终版.pth”）很快就会失控。版本控制的核心目标不是“备份文件”，而是建立可追溯、可复现、可协作的实验资产管理系统。本章聚焦Git与DVC（Data Version Control）的协同机制，解决“代码版本”与“数据/模型版本”脱节的核心痛点。
4.1 核心原理：Git管代码，DVC管数据
Git本身并不适合直接管理大文件（如数据集、模型权重），因为Git仓库会迅速膨胀，clone和push变得极其缓慢。DVC的核心设计思想是“指针文件+内容寻址存储”：DVC将实际的大文件存储在独立的缓存或远程存储中，而在Git仓库中只保留一个极小的.dvc指针文件（通常只有几百字节），该文件记录了数据文件的哈希值（MD5或SHA256）。当Git提交时，实际提交的是这个指针文件；当需要恢复数据时，DVC根据指针文件中的哈希值从缓存或远程存储中拉取对应内容。
这种机制带来的关键优势是：Git提交历史与数据版本完全同步。每次实验的代码、配置、.dvc指针文件被一起提交，形成一个不可分割的“实验快照”。任何人checkout到某个commit，执行dvc pull，就能获得与该commit完全匹配的数据和模型版本，实现真正的可复现性。
| 维度 | Git | DVC |
|---|---|---|
| 管理对象 | 代码、配置、脚本、.dvc指针 | 数据集、模型权重、大体积指标文件 |
| 存储方式 | Git对象库（.git目录） | 本地缓存（.dvc/cache）+ 远程存储 |
| 版本标识 | commit SHA（40位十六进制） | 文件内容哈希（MD5/SHA256） |
| 操作命令 | git add/commit/branch/merge | dvc add/push/pull/repro |
| 适用场景 | 代码逻辑变更追踪 | 数据更新、模型迭代、实验复现 |
4.2 操作流程：从初始化到实验复现
在Edge AI压缩项目中，推荐的工作流程如下：
- 初始化环境：在项目根目录执行
git init和dvc init，生成.dvc目录和配置文件。 - 添加数据/模型：使用
dvc add data/raw_images，DVC会计算哈希、移动文件到缓存，并生成data/raw_images.dvc指针文件。 - 配置远程存储：
dvc remote add -d myremote s3://my-bucket/dvc-store或使用SSH/共享盘，然后dvc push上传实际数据。 - 常规开发循环：修改代码 →
git add . && git commit -m "添加量化感知训练脚本"→ 运行实验 → 记录指标。 - 数据更新：当数据集或模型更新时，重新执行
dvc add，生成新的.dvc文件，然后git提交新的指针。 - 实验复现：新成员clone仓库后执行
dvc pull，即可获取与当前commit匹配的所有数据文件。
# 典型命令序列
git init
dvc init
dvc remote add -d myremote /mnt/shared/dvc-store
dvc add datasets/edge_imgs
git add datasets/edge_imgs.dvc .dvc/config
git commit -m "添加边缘设备图像数据集 v1.0"
dvc push
# 后续实验...
dvc repro # 根据dvc.yaml自动执行pipeline并更新指标4.3 实战场景：压缩实验的多版本管理
假设你正在开发一个针对Cortex-M4的模型压缩项目，需要对比浮点基线模型、INT8 PTQ（训练后量化）模型和QAT（量化感知训练）模型的性能。三个模型的数据集、训练脚本、评估指标各不相同，且需要频繁回溯对比。
初始状态：项目目录包含src/（训练代码）、configs/（压缩配置）、data/（原始数据集）、models/（训练产物）、metrics/（评估结果CSV）。
操作步骤：
- 将
data/和models/纳入DVC管理，src/和configs/由Git管理。 - 创建三个Git分支：
baseline、ptq_int8、qat，分别进行实验。 - 在
ptq_int8分支上，修改configs/quant.yaml中的量化配置，运行dvc repro，DVC自动追踪输入数据、代码、配置的变化，生成新的模型文件和指标。 - 提交时使用
git add . && git commit -m "PTQ实验：对称量化，精度损失2.1%"，同时dvc push上传新模型。 - 切换回
baseline分支时，git checkout baseline后执行dvc checkout，工作区的模型和数据自动恢复到基线版本。
git commit -m "QAT w8a8: acc 92.3% (-1.8%), latency 12ms (-35%), size 98KB (-75%)"。这比查看metrics文件更快定位目标实验。
4.4 常见误区与复盘
误区一：把所有文件都交给DVC管理。DVC适合管理变化频率低但体积大的文件（数据集、模型权重）。对于频繁修改的代码、配置，应使用Git。将代码纳入DVC会导致每次修改都产生新的哈希和缓存，浪费存储且混淆版本。
误区二：忽略.dvcignore文件。与.gitignore类似，DVC支持.dvcignore排除不需要追踪的文件（如临时日志、中间缓存）。不配置该文件会导致缓存目录膨胀，dvc status输出混乱。
误区三：在Git LFS和DVC之间犹豫不决。Git LFS适合管理单个大文件（如预训练模型），但无法表达“数据集+代码+配置”的组合版本关系。DVC的pipeline功能（dvc.yaml）能自动追踪数据依赖和指标变化，更适合实验管理。
误区四：不进行远程存储备份。DVC的本地缓存如果丢失，所有数据版本将无法恢复。必须配置远程存储（S3、SSH、NAS）并定期dvc push。
dvc pull的情况下直接运行实验，会使用旧数据产生“伪复现”。建议在CI/CD流程中加入dvc pull和dvc status --check步骤，确保实验环境一致性。
4.5 实验指标追踪与对比
DVC的dvc metrics命令可以自动提取实验指标（如accuracy、latency）并生成对比表。在dvc.yaml中定义指标文件路径后，每次dvc repro会自动更新指标。使用dvc metrics diff可以快速查看不同commit之间的指标变化。
# dvc.yaml 示例
stages:
train:
cmd: python src/train.py --config configs/quant.yaml
deps:
- src/train.py
- configs/quant.yaml
- data/edge_imgs
outs:
- models/model_int8.tflite
metrics:
- metrics/accuracy.json:
cache: false
evaluate:
cmd: python src/evaluate.py --model models/model_int8.tflite
deps:
- src/evaluate.py
- models/model_int8.tflite
metrics:
- metrics/latency.json:
cache: false通过dvc metrics diff --all，可以列出所有历史实验的指标对比，快速定位最优模型。结合Git分支，可以形成“实验矩阵”：每个分支代表一种压缩策略，每个commit代表一次参数调整，指标变化一目了然。