Reproducibility & Version Control

Somewhere in your future is a moment of quiet panic: a result you produced months ago, a stakeholder asking how, and no way to rerun it. Reproducibility is the discipline that prevents that moment. It means anyone with your project can run it and get the same answer, and it rests on four things being captured: the code, the data, the randomness, and the environment. Get those under control and your analysis stops being a personal artifact and becomes something the world can check, which is what turns a claim into evidence.

“It works on my machine” is the enemy. A result reproduces only when four separate things are the same as when it was first produced. Miss any one and the answer can quietly change.

Three of the four are quick habits. Set a seed (np.random.default_rng(42)) and random operations repeat exactly. Pin the environment by listing every package at an exact version in a requirements.txt, ideally inside a per-project virtual environment. And hash the data, a short fingerprint of its exact contents, so you can prove later whether it changed. The fourth pillar, versioning the code, is big enough to be the rest of this chapter.

Git is a version control system: it records your project as a sequence of snapshots called commits, each with a message, an author, and a timestamp. It answers what changed, when, why, and by whom, lets you return to any past state, and makes experimentation safe because nothing is ever truly lost.

The everyday loop is three steps. You edit files in your working folder. You stage the changes you want to record with git add, choosing what goes in. And you commit them with git commit, saving a snapshot with a message. That is 90 percent of Git.

A companion habit lives here too: the .gitignore file, a list of things Git should never track. Large data files, generated outputs, and above all secrets like API keys and passwords belong out of version control. Notebook 3 shows a .gitignore making a committed secret and a data folder vanish from Git's view, which is a mistake you very much want to prevent, not fix.

A branch is a parallel line of work. You branch off main to try an idea, commit freely without risking the stable version, and when it is ready you merge it back. This is how one person experiments safely and how a whole team builds in parallel without overwriting each other.

git switch -c add-feature     # branch off and move onto it
git commit -am "Add region feature"
git switch main
git merge --no-ff add-feature   # bring the finished work back

Sometimes two branches change the same line differently, and Git cannot know which is right. It stops and marks the spot, a merge conflict. This is not an error but a request for a human decision: Git kept both versions safe and is asking you to choose. You edit the file to the version you want, remove Git's marker lines, and commit the resolution. Notebook 4 creates a real conflict over a threshold value and walks the resolution end to end, finishing with the branching commit graph.

Scale this branch-commit-merge cycle across a team on a shared host, GitHub, GitLab, or Bitbucket, and you have how essentially all modern software and data science is built. A pull request proposes a branch's changes for review before they merge, adding a human check to the version history.

Editors and desktop apps put a friendly face on Git, but underneath, and for most developers and statisticians day to day, version control lives in the command line. The terminal is universal (the same commands work on every machine and every host), scriptable (you can automate it), and it is where every tutorial, error message, and teammate's instructions are written. A handful of commands cover almost everything you will ever do.

Here is the whole everyday rhythm of working with a shared repository, from getting a copy to sending your work back, as it actually looks in a terminal.

# get your own copy of a project that lives on GitHub
$ git clone https://github.com/acme/sales-analysis.git
$ cd sales-analysis

# before starting work, pull the latest changes teammates have pushed
$ git pull

# make a branch for your task, so main stays stable
$ git switch -c add-region-breakdown

# ...edit analysis.py, add a chart... then see what changed
$ git status
  modified:   analysis.py
$ git diff                          # review the exact line changes

# stage, commit with a clear message, and push the branch to GitHub
$ git add -A
$ git commit -m "Add revenue breakdown by region"
$ git push -u origin add-region-breakdown

# open a pull request on GitHub, get review, then it merges into main

That is the loop nearly everyone repeats many times a day: pull, branch, edit, add, commit, push, open a pull request. The one golden habit inside it is pull before you push, so you build on your teammates' latest work and avoid surprise conflicts. When a conflict does happen, it is the same event from the branching section, resolved the same way.

A developer runs these dozens of times a day almost without thinking. A statistician or data scientist uses the very same commands to version analysis scripts, notebooks, and reports, and to sync a project with collaborators through a shared remote. Learn these ten and you are fluent in the language every team, tool, and tutorial speaks.

Once your code lives in a shared repository, you can make a robot watch it. Continuous Integration (CI) means that every push automatically triggers a fresh build and a run of your tests, in a clean environment, so a broken change is caught in minutes rather than discovered in production. Continuous Delivery / Deployment (CD) goes one step further: when the tests pass, the result is automatically packaged and released, or even deployed live.

For this book the connection is direct. CI is reproducibility enforced by machine. The pipeline checks out your exact commit, rebuilds the pinned environment, reruns the analysis from scratch, and fails loudly if a number moves or a test breaks. If it cannot reproduce your result on a clean server, neither can anyone else.

The pipeline itself is just a file in your repository, so it is versioned like everything else. Here is a minimal GitHub Actions workflow that, on every push, sets up Python, installs the pinned dependencies, and runs the test suite.

name: tests
on: [push]                       # run on every push
jobs:
  test:
    runs-on: ubuntu-latest          # a fresh, clean machine each time
    steps:
      - uses: actions/checkout@v4    # get the exact commit
      - run: pip install -r requirements.txt   # rebuild the pinned environment
      - run: pytest                   # rerun the tests; fail loudly if anything broke

Data scientists lean on the same machinery: a pipeline can rerun a notebook end to end, validate that a model still clears an accuracy bar, regenerate a report, or trigger a retraining job. It is the automated backbone of the reproducible, monitored workflow the MLOps chapter describes.

You rarely have to leave your editor to use Git, because version control is now built into nearly every serious development and analysis tool. The commands underneath are identical; the difference is a graphical front door, staging changes with a checkbox, seeing a colored diff in the margin, committing from a panel, and resolving a conflict in a visual three-way view.

The lesson is that Git is the shared plumbing beneath a dozen different front doors. A developer might commit from the VS Code sidebar, a statistician from the RStudio or SAS Studio Git pane, and a data engineer from the terminal, and they all push to the same GitHub repository and see the same history. That commercial statistical platforms like SAS now build in Git is the clearest sign of how universal version control has become: it is no longer a programmer's tool, but everyone's.

Work through these in order. The Git notebooks run real commands against a disposable repository, so you see an actual history, branch, and conflict, not a description of one.

Notebooks run on pandas, numpy, matplotlib, and the built-in subprocess plus a real git (preinstalled on Colab).

In machine learning the stakes are higher, because a model has more moving parts to pin: not just code and data but the exact split, the hyperparameters, the framework versions, and every seed. The field has built dedicated tools for it, and they are all doing, at scale, what the notebooks here do by hand.

Five exercises, one per notebook area. Full solutions are in the companion solutions notebook.

Eight questions on the four pillars, Git basics, branching, and experiment tracking. Answer them, hit Check Answers, and keep refining until you score 100%. Your progress is saved.