DVC for Data Versioning: Treating Datasets Like Code

Git is excellent at tracking code. It's terrible at tracking a 2GB dataset or a trained model checkpoint — and yet most ML projects start out trying to force both into the same workflow. DVC Data Versioning is a small project built specifically to practice the alternative: Data Version Control (DVC), which extends Git-like versioning to data and models without bloating the actual Git repository.

Why this problem is worth solving deliberately

The moment an ML project has more than one person, or more than one training run you might want to go back to, "which version of the dataset produced this model" becomes a real question. Without an answer, reproducibility quietly breaks — you can't retrain the exact model that's in production because the data it was trained on has since been overwritten or modified.

What DVC actually does

DVC stores lightweight metadata files in Git (which is good at tracking small text changes) while the actual large data and model files live in separate storage, referenced by hash. Checking out a different Git commit checks out the matching version of your data automatically — the same mental model as Git, extended to files Git was never designed to handle well.

What this project focuses on

This is a focused, practical exercise in the reproducibility half of MLOps: making sure that "train the model" is always a repeatable action tied to a specific, retrievable version of the data — not a one-time event that can never be exactly reproduced again. It's a small piece of the MLOps puzzle, but it's the piece that makes every other piece (CI/CD, automated retraining, rollback) actually trustworthy.

Git vs. DVC

Tool	What it tracks
Git	Code changes — small text diffs
DVC	Data and model files — large binaries, referenced by hash

Without data versioning, "which dataset produced this model" quietly stops having an answer.

Built in Python. Source on GitHub.