Lecture 2 - Version Control for Data Science

ANSCI 4040/6040 - Fall 2026

Dr. Hostens

Today’s goal

By the end of today, you should be able to explain:

Why version control exists, what a Git workflow is doing, and what parts of a data-science project should be versioned.

We will learn this by experiencing the problem first.

Part 1 — The data-science crime scene

Your mission: reproduce the published result.

RMSE = 0.18 kg CH₄/cow/day

You have a folder:

analysis.py
analysis_final.py
analysis_final2.py
analysis_FINAL_really.py
milk_production.csv
milk_production_cleaned.csv
data_new.csv

What went wrong?

What information are we missing?

  • Which version was used?
  • What changed?
  • Who changed it?
  • When did it change?
  • Why was it changed?
  • Can we go back?
  • Can someone else reproduce it?

This is the problem version control is designed to solve.

Part 2 — Git without computers

Can you build the most probable project history:

START → [v1] → [v2] ...

Commit

A commit is a recorded checkpoint.

A useful mental model:

Git remembers how the project got here.

Branching

Student 1 and student 2 need to try different ideas.

                 ┌──── Student 1: new model ──────┐
main ────────────┤                                ├── merge
                 └──── Student 2: new variable ───┘

Question for you:

Why not just overwrite the same files?

A branch lets us experiment without destroying the main line of work.

Pull & merge

Two people have different histories.

You:      A ─ B ─ C
                 \
Remote:   A ─ B ─ D

Pull → bring remote changes into your local project.

Merge → combine histories.

And sometimes:

Merge conflict.

That is not a Git failure. It is Git asking a human to make the scientific decision.

What should we version?

What about these files?

analysis.py
model_parameters.yml
README.md
requirements.txt

What should we version?

What about these files?

raw_big_dataset.csv
model.pkl
temporary_plot.png
outputs/

What should we version?

What about these files?

password.txt
API_key.txt
.env

Version controlled

YES

  • code

  • configuration

  • documentation

  • small text-based metadata

Version controlled

NO

  • large raw data

  • temporary files

  • secrets

  • generated outputs

  • local machine files

This leads to .gitignore.

Tell Git what not to track.

.gitignore

Typical python .gitignore:

# Local / temporary files
.DS_Store
*.tmp

# Python cache
__pycache__/

# Generated outputs
outputs/

# Secrets
.env
*.key

The data-science twist

A result depends on more than code.

          code
            ↓
raw data → preprocessing → model → result
            ↑                ↑
        parameters       environment

Reproducibility means thinking about the whole chain.

Git is one piece of that system — not the entire system.

Why version control when I work alone?

Why would a solo scientist use version control?

Then ask:

What would you want to undo, compare, or understand six months from now?

The answer is often:

“I want to know what I did — and be able to go back.”

One mental model to take home

       experiment
           ↓
       change files
           ↓
        commit
           ↓
   keep a reliable history
      ↙           ↘
   branch         collaborate
      ↘           ↙
          merge

  • Version control is not mainly about commands.

  • It is about history, reproducibility, and safe change.