版本控制基础：Git与DVC在数据集管理中的角色与核心概念
说到版本控制，大家第一反应肯定是 Git。没错，Git 在代码管理领域已经是事实标准了。但数据集管理呢？我见过太多团队把几个 GB 的 CSV 文件直接塞进 Git 仓库，结果每次 clone 都要等半小时，pull 的时候冲突一堆，最后整个仓库膨胀到几十个 GB。
说白了，Git 设计出来是管代码的，不是管数据的。代码是文本文件，差分对比非常高效。但数据集呢？一个 500MB 的 Parquet 文件，改了一行数据，Git 会把它整个重新存一遍。你想想看，这能行吗？
所以就有了 DVC——Data Version Control。它不是要替代 Git，而是跟 Git 配合着用。我习惯把 Git 比作「代码的账本」，DVC 则是「数据的索引目录」。两者各司其职，才能把数据集版本管理清楚。
Git 在数据集管理中的角色
Git 的核心能力是跟踪文本文件的变更历史。对于数据集来说，它适合管理以下几类内容：
- 数据处理的脚本和配置文件——比如 ETL 脚本、数据清洗的 Python 代码
- 数据集的元信息——schema 定义、数据字典、标注说明文档
- 小规模的样本数据——几百 KB 以内的测试集或 demo 数据
但 Git 对大型二进制文件的支持非常差。我记得有一次，团队里有人把训练好的模型文件（1.2GB）直接 commit 了，结果整个仓库 size 暴涨，其他人 pull 的时候直接卡死。嗯，从那以后我们立了规矩：超过 10MB 的文件一律不准进 Git。
DVC 的核心概念与角色
DVC 解决的核心问题就一个：让 Git 能够「引用」大数据文件，而不需要真的存储它们。
它的工作流程是这样的：
- 你有一个 10GB 的数据集文件
train.parquet - DVC 会生成一个很小的
train.parquet.dvc文件，里面只记录文件的哈希值和路径 - 你把
.dvc文件提交到 Git，真正的数据文件放到远程存储（S3、GCS、NAS 等） - 其他人 pull 代码时，通过
.dvc文件就能从远程存储拉取对应的数据版本
说白了，DVC 就是给大数据文件做了一个「指针」或「快捷方式」。Git 管理的是这些指针，真正的数据存在别处。
核心概念速览：
- .dvc 文件：数据文件的元信息，包含 md5 哈希、路径、大小
- DVC cache：本地缓存目录，存放所有被追踪的数据文件
- DVC remote：远程存储后端，支持 S3、GCS、Azure Blob、SSH、本地目录等
- dvc.lock：记录 pipeline 中各步骤的依赖和输出文件的哈希值
Git 与 DVC 的分工协作
我习惯用一个表格来说明两者的分工，这样更直观：
| 维度 | Git | DVC |
|---|---|---|
| 管理对象 | 代码、配置文件、文档 | 数据集、模型文件、大二进制文件 |
| 存储方式 | 直接存储文件内容 | 存储文件哈希和指针，实际数据存远程 |
| 差分能力 | 行级差分（文本文件） | 文件级差分（仅记录哈希变化） |
| 分支合并 | 原生支持，自动合并 | 需要手动处理数据文件冲突 |
| 远程存储 | GitHub、GitLab、Bitbucket | S3、GCS、NAS、HDFS 等 |
| 适用场景 | 代码版本迭代、多人协作开发 | 数据集版本追踪、ML 实验复现 |
你可能会问：为什么不能只用 DVC？因为 DVC 不管理代码的版本啊。你想想看，数据清洗脚本改了，DVC 不会知道。只有 Git 才能追踪代码的每一次变更。两者缺一不可。
DVC 的核心工作流
我给大家演示一下最常用的 DVC 命令，这样你就能理解它的工作方式了：
# 初始化 DVC（在已有 Git 仓库中执行）
dvc init
# 添加数据集到 DVC 追踪
dvc add data/train.parquet
# 这会在 data/ 目录下生成 train.parquet.dvc 文件
# 同时把原始文件移动到 .dvc/cache 中，创建一个符号链接
# 配置远程存储（以 S3 为例）
dvc remote add -d myremote s3://my-bucket/dvc-store
# 推送数据到远程
dvc push
# 从远程拉取数据
dvc pull
# 切换数据集版本（通过 Git 切换分支后）
dvc checkout这里有个细节要注意：dvc add 之后，原始文件会被替换成一个符号链接。你编辑的还是那个文件，但 DVC 会在背后管理它的版本。我第一次用的时候也被这个搞懵了，以为文件丢了。其实没有，它只是被移到了 cache 目录。
💡 个人经验： 我建议在项目根目录创建一个 .dvcignore 文件，跟 .gitignore 类似。把不需要追踪的临时数据、中间结果排除掉。比如 *.tmp、__pycache__/ 这些。不然 DVC 会扫描所有文件，影响性能。
数据集的版本标识与回溯
Git 用 commit SHA 来标识版本，DVC 则用文件的 md5 哈希来标识。每次 dvc add 或 dvc repro 都会重新计算哈希，如果文件内容变了，哈希就会变。
这意味着什么？意味着你可以精确地回溯到任何一个历史版本的数据集。比如：
# 查看某个数据文件的版本历史
dvc log data/train.parquet
# 回退到某个历史版本
git checkout <commit-hash> # 先切到对应的代码版本
dvc checkout # 再切到对应的数据版本我遇到过最典型的场景是：训练了一个模型，效果很好。但过了两周，数据集被更新了，模型效果下降。这时候怎么办？用 Git + DVC 回溯到训练时的代码和数据版本，重新跑一遍，就能复现当时的结果。没有版本控制，这种场景基本无解。
Git 与 DVC 的版本关系图
下面这张图展示了 Git 和 DVC 如何协同管理代码与数据的版本：
实际项目中的目录结构
最后，我分享一下我在实际项目中常用的目录结构，你可以直接参考：
my-ml-project/
├── .git/ # Git 仓库
├── .dvc/ # DVC 配置和缓存
│ ├── cache/ # 本地数据缓存
│ └── config # DVC 远程存储配置
├── data/
│ ├── train.parquet # 实际数据文件（符号链接）
│ ├── train.parquet.dvc # DVC 指针文件
│ ├── test.parquet
│ └── test.parquet.dvc
├── models/
│ ├── model.pkl # 模型文件（符号链接）
│ └── model.pkl.dvc
├── src/
│ ├── train.py
│ └── evaluate.py
├── configs/
│ └── experiment.yaml
├── .gitignore
├── .dvcignore
└── dvc.lock看到没？.dvc 文件跟数据文件放在同一个目录，这样结构清晰，一眼就能看出哪些文件是被 DVC 管理的。我个人习惯在 .gitignore 里加上 *.parquet、*.pkl 这类大数据文件的通配符，确保它们不会被误提交到 Git。
好了，这一章的核心内容就是这些。Git 和 DVC 的关系搞清楚了，后面讲版本冲突的时候你才能理解冲突到底发生在哪一层——是代码冲突还是数据冲突，处理方式完全不同。