The Daily Git-DVC Workflow

Change data deliberately

The everyday DVC workflow follows a predictable rhythm once you've internalized it. After you make an intentional change to a tracked data file, run dvc add data/file to recompute its checksum and update the pointer. Then stage the changed .dvc pointer file (and any .gitignore rules DVC manages) in Git, and commit them together with whatever code change the data update relates to - so the two histories stay linked. If your project has a configured DVC remote, push the actual large data content separately with dvc push, since Git only ever carries the small pointer.

$ dvc add data/customers.csv
$ git add data/customers.csv.dvc .gitignore
$ git commit -m "Refresh customer dataset to Q3 snapshot"
$ dvc push

On the other side, a teammate who pulls that commit down with git pull only gets the small pointer file - the actual data isn't there yet. They then run dvc pull to fetch any missing content from the remote (or dvc checkout, if the content happens to already be sitting in their local cache from a previous version and just needs restoring into the workspace). In continuous integration (CI - the automated checks that run against every proposed change), it's worth explicitly failing the build if tracked data unexpectedly differs from what's recorded, rather than silently continuing with the wrong data.

Tip: Review a changed .dvc checksum in a pull request exactly the way you'd review a change to a dependency lockfile: it represents a real, meaningful change, and the accompanying commit message should explain why the data changed, not just that it did.