จัดการเวอร์ชันข้อมูลและโมเดล

Git tracks your code beautifully, but a model also depends on data and weights. To reproduce a result you must version those too. 🗂️

Datasets grow, get cleaned, or get relabeled. If you cannot say which version of the data trained a model, you can never rebuild that exact result.

A run is reproducible only when three things are pinned together: the code, the data, and the trained weights. Drop any one and the result drifts.

You do not store huge files in Git. Instead you record a hash, a short fingerprint of the dataset, so any change is instantly detected.

DVC, Data Version Control, layers on top of Git to version large files. It stores a tiny pointer in Git and the real data in remote storage.

One command tells DVC to manage a file. It replaces the heavy data with a small .dvc pointer that Git can safely commit.

The actual bytes live in cloud storage, not your repo. dvc push uploads them so teammates can pull the exact same files later.

Save weights with a clear name that ties them to a run. Pairing a checkpoint with its commit and data hash makes the model fully traceable.

When a model is good enough to ship, mark that moment. A Git tag like v1.0 lets you return to the exact code, data, and weights anytime.

With everything versioned, recovery is two steps: checkout the commit, then dvc pull. You get the identical inputs that produced the original model.

When anyone can rebuild a result from scratch, your work becomes auditable. That trust is what separates a hobby project from production ML.

How does DVC keep large datasets out of Git?

You learned to version data and models: hash inputs, track files with DVC, push to remote, and tag releases so any run is reproducible. 🎉