Version Control and Distribution of Code

Why Version Control¶

If you’ve ever ended up with Final.doc, then Final_v2.doc, then Final_v2_reallyfinal.doc — you’ve already felt the problem a version control system (VCS) solves. A VCS keeps a repository of every version of every file, replicated on each contributor’s machine, and can answer: what changed between the run that worked and now? Who changed the code or data, and why? Can I get back exactly what we had before? Git is the dominant example — a distributed VCS, meaning every clone carries the full history, not just a snapshot Chacon & Straub, 2014.

Branching, Merging, and Pull Requests¶

A branch is an independent line of work off the main history; git branch shows which one you’re on. Two people can each commit to their own branch, then merge one into the other — Git resolves this automatically when the changes don’t overlap, and asks you to resolve a conflict by hand when they do (e.g., two different values proposed for the same line).

A pull request (or “merge request” on GitLab) is a proposal to merge one branch into another, opened for discussion and review before it happens — the mechanism, on GitHub, by which an outside contributor proposes a change without touching the main branch directly.

Hosting and Long-Term Availability¶

Git still needs a server to host the shared repository: a hosting service (GitHub, GitLab, Bitbucket, or the non-profit Codeberg — see this comparison) or a self-hosted server, which trades convenience for control and a real maintenance burden.

Cloning (a native Git feature) gets you a local copy without changing who owns the project. Forking (a hosting-service feature, not a Git one) makes you the owner of your own copy, which you can modify freely and later propose back to the original project via a pull request.

Releases and Distribution¶

A Git tag is a named pointer to a specific commit; GitHub turns a tag into a release — a changelog, a link to that commit, and a bundle of the source code (e.g., NumPy 2.0, or Node.js’s odd-numbered “experimental” releases). What a release actually ships varies:

• Source + install instructions (e.g., the NVM install script)

• Source + build instructions (e.g., building PyTorch from source)

• Prebuilt binaries (e.g., VLC, or a PyPI package installed with pip)

• All of the above (e.g., Node.js: binaries, build docs, and npm)

Dependencies are usually kept out of the repository and declared instead (requirements.txt, package.json) — pinning exact versions (package-lock.json) is what makes an install reproducible later.

Reproducible Environments¶

The same code can fail on a different OS, a different library version, or a port already in use — “works on my machine” is a real, recurring failure mode. Two ways to package an environment against it: a virtual machine (a full OS emulation — heavy, but complete) or a container, most commonly Docker (lightweight, Linux-kernel-based, configured in a Dockerfile). Within a single language, Python’s venv isolates dependencies per project — commit requirements.txt, never the .venv/ folder — and conda goes further, managing Python itself alongside non-Python dependencies (compilers, CUDA, R) via a committed environment.yml.

CI/CD¶

Continuous Integration automates checking new code on every push, on a clean machine: if it builds and the tests pass there, it’ll work for your reviewer, your colleague, and future you. Continuous Deployment then publishes something automatically once checks pass — a release, a doc site, a Docker image. On GitHub, this is Actions: workflows built from reusable blocks plus shell commands, which can also gate a pull request on tests passing.

Version Control and Open Science¶

Version control supports reproducibility directly: it ties changes in results to changes in code, gives publications a stable reference point, and automates the change history that makes replication attempts possible Ram, 2013. Lecture 4 picks this up for data and computational environments specifically.

Further Resources¶

• Pro Git — the free, canonical Git book (Chacon & Straub, cited in References)

• Comparison of source-code-hosting facilities

• GitHub Arctic Code Vault

• Semantic Versioning 2.0.0

• Docker and conda documentation