Why Git Needs DVC

Two histories, one project

Git is excellent at tracking source code and small text files, keeping a full history of every change - but it was never designed for datasets that can be hundreds of megabytes or gigabytes. Repeatedly committing large binary or CSV files directly into Git bloats every clone of the repository forever, since Git keeps a copy of every version of every file it has ever tracked. Data Version Control (DVC) solves this by keeping only a small .dvc pointer file inside Git, while the actual large data content lives somewhere else - a local cache on disk, or shared storage elsewhere called a remote.

That small pointer file records the data's file path and a checksum: a digital fingerprint calculated from the file's exact contents, similar in spirit to the hash concept from the GGUF module earlier. dvc checkout reads the checksum recorded in the current Git commit and copies the exact matching data into your working directory - a step called materializing the data, because up until that point it exists only as a pointer, not as an actual file you can open. dvc status compares what's actually sitting in your working directory right now against what the recorded checksum says it should be, and reports a mismatch if the two disagree.

Analogy: Git keeps the library's catalog card for a book - title, author, a short pointer to where it lives. DVC manages the actual warehouse box the book sits in, sealed and labeled with a tamper-evident fingerprint, so anyone can tell at a glance whether the box's real contents still match what the catalog card claims.