Why Version Control

You have probably named a file something like analysis_final_v2_REAL_final.R. Everyone has. This approach breaks down quickly. Version control solves this problem.

The problem with file renaming

Scientists often track changes by copying files and appending version numbers or dates to the filename. A project directory ends up looking like this:

project/
  deseq2_analysis.R
  deseq2_analysis_v2.R
  deseq2_analysis_v2_fixed.R
  deseq2_analysis_FINAL.R
  deseq2_analysis_FINAL_v2.R
  deseq2_analysis_FINAL_REAL.R

This creates several problems. You cannot tell what changed between versions. You do not know why a change was made. You cannot easily go back to a specific version. If two people edit the same file, you have no way to merge their changes.

What version control does

Version control is a system that records changes to files over time. Every time you save a snapshot, the system records exactly what changed, when it changed, and who changed it. You can:

Go back to any previous version of any file.
See exactly which lines changed between two versions.
Read a message explaining why each change was made.
Work on experimental changes without breaking your main code.
Merge changes from multiple people into one file.

Git is the standard

Git is the most widely used version control system. Linus Torvalds created it in 2005 to manage Linux kernel development. It is now used across software engineering, data science, and bioinformatics.

Git runs on your computer. It does not require an internet connection. Every copy of a Git repository contains the full history of every file.

What to version control

Track these files with Git:

Analysis scripts (R, Python, shell scripts)
Notebooks (Jupyter, R Markdown)
Configuration files (nextflow.config, sample sheets)
Small data files (gene lists, metadata tables under 1 MB)
Documentation (README, methods descriptions)
Dockerfiles and environment files

What NOT to version control

Some files should never go into a Git repository. They are too large, too sensitive, or generated from other files.

Large data files: FASTQ, BAM, H5AD, and other sequencing files. These can be gigabytes or terabytes. Git is not designed for large binary files.
Sensitive data: patient identifiers, clinical records, API keys, passwords. These must never be committed to a repository.
Generated output: plots, compiled binaries, HTML reports. These can be regenerated from the source code.
Temporary files: .Rhistory, __pycache__/, .DS_Store.

Git provides a file called .gitignore that tells it to skip these files. You list patterns for files and directories that should be ignored.

Git vs GitHub

These are different things.

Git is a command-line tool that runs on your computer. It tracks changes to files in a local repository.

GitHub is a website that hosts Git repositories online. It adds features like pull requests, issue tracking, and collaboration tools. GitLab and Bitbucket are alternatives to GitHub.

You do not need GitHub to use Git. But GitHub makes it easy to share code, collaborate with others, and back up your work.

Reproducibility

Version control is essential for reproducible research. When you publish a paper, reviewers and readers need to know exactly which code produced your results.

With Git, you can tag the exact version of your code used for a publication. Anyone can download that version and reproduce your analysis. Many journals now require that code be publicly available. A Git repository satisfies this requirement.

Without version control, you are relying on file names and memory to track which script produced which figure. This fails as projects grow in complexity.

Summary

File renaming does not scale as a version tracking strategy.
Git records every change, who made it, and why.
Track scripts, configs, and small data files. Exclude large data, sensitive information, and generated output.
Git runs locally on your computer. GitHub hosts repositories online.
Version control is a requirement for reproducible bioinformatics research.