Version Control for Science
Tracking every change to code and inputs so any result can be traced to the exact state that produced it.
The Traceable Record
Version control systems record every change to a set of files, who made it, when, and why. For scientific computing the payoff is traceability: any result can be tied to the exact code and inputs that produced it, identified by a commit. Without this, a result is unmoored, because the code has moved on and no one can be sure which version generated the figure in the paper.
What It Enables
- Reproducibility: check out the exact commit and rerun to regenerate a result.
- Bisection: find the change that introduced a regression by searching commit history.
- Collaboration: multiple people change the code without overwriting each other.
- Branching: develop and test a change in isolation before merging it.
Versioning More Than Code
Code is not the only thing worth versioning. Input files, configuration, analysis scripts, and small reference data all belong under version control, because a result depends on all of them. Large data and binary outputs are handled with dedicated extensions for large files, so the repository stays manageable while still pinning the exact data version used.
Tagging Results
The discipline that connects version control to the published record is tagging: marking the exact commit that produced each significant result or deposit, so the state is recoverable indefinitely. A DOI-minting deposit points to such a tagged state, giving a permanent, citable snapshot. This is precisely how a reproducibility record is built: every published number traces to a commit, and every commit can be checked out and rerun.
Version control is the foundation beneath regression testing, continuous integration, and reproducibility. None of them work without a precise notion of code state, and version control is what supplies it. It is the least glamorous and most load-bearing practice in credible scientific computing.