At some point in every data scientist’s career, something goes wrong with a file.

Maybe you were iterating on a model, made a change that seemed promising, kept going, and then realized – three hours later – that the version you had before the change was actually better. But you can’t get back to it because you saved over it.

Maybe you have a folder that looks like this:

analysis_final.ipynb
analysis_final_v2.ipynb
analysis_final_v2_FIXED.ipynb
analysis_final_v2_FIXED_actually_final.ipynb
analysis_USE_THIS_ONE.ipynb

Maybe you’re collaborating with someone and you’ve both edited the same script and now neither version is complete.

All of these problems have the same solution: version control. And the standard version control tool – in data science, software engineering, and virtually every technical field – is Git.

Git has a reputation for being intimidating. That reputation is partially deserved – it has a vast feature set and a command-line interface that can feel opaque. But here’s the honest truth: for data science work, you need maybe 10% of what Git can do. That 10% is learnable in an afternoon and will immediately change how you work.

This guide covers exactly that 10%.

What Git Actually Is

Git is a version control system – a tool that tracks changes to files over time, stores a complete history of those changes, and allows you to navigate that history freely.

Think of it like a detailed undo history for your entire project – not just the last 20 keystrokes, but every meaningful change you’ve ever saved, permanently recorded with a timestamp, a description, and the ability to return to any point.

Beyond individual use, Git also enables collaboration – multiple people working on the same project without overwriting each other’s work. And it powers platforms like GitHub and GitLab, which provide cloud-hosted storage for Git repositories.

But for now, think of Git simply as: a system that makes “I want to go back to how this was two weeks ago” a one-command operation instead of an impossible wish.

Why Data Science Specifically Needs Version Control

Software engineers have used version control for decades. Data scientists have been slower to adopt it – and the reasons are understandable but costly.

Data science work is inherently experimental. You try things. You change parameters. You swap features in and out. You refactor a preprocessing pipeline and then wonder if the old one was actually better. You have notebooks, scripts, data files, model weights, and output figures all evolving simultaneously.

Without version control, this experimental nature becomes a liability. With it, experimentation becomes safe – because every state worth preserving can be recovered.

Specifically, Git solves these common data science pain points:

The “which version produced this result?” problem. When a result is linked to a specific commit in Git history, you can always retrieve the exact code that generated it – even months later.

The “I broke something and can’t undo it” problem. Git lets you roll back to any previous state instantly.

The “I want to try something risky without destroying what’s working” problem. Git branches let you experiment in isolation and merge back only if it works.

The “my collaborator and I are editing the same file” problem. Git tracks changes from multiple contributors and provides tools for merging them cleanly.

The Core Concepts (Plain English)

Before any commands, the concepts. These five ideas cover everything you need to understand.

Repository (Repo)

A repository is a tracked project folder. When you initialize Git in a folder, it starts recording the history of every file inside it. Everything Git knows about your project lives in the repository.

Think of it as the difference between a regular folder and a folder with a built-in time machine.

Commit

A commit is a saved snapshot of your project at a specific moment in time.

Unlike saving a file – which overwrites the previous version – a commit adds a new entry to your project’s history while keeping all previous entries intact. Each commit has a unique identifier, a timestamp, your name and email, and a message you wrote describing what changed.

A well-maintained commit history looks like a legible log of your project’s evolution. A commit message like “Add HR drift feature and retrain model” tells you exactly what happened and when.

Staging Area

Git doesn’t automatically include every changed file in your next commit. Instead, you choose which changes to include by staging them first.

This two-step process – stage, then commit – gives you deliberate control over what goes into each snapshot. Think of it as packing a box before sealing it. Staging is putting things in the box. Committing is sealing and labeling it.

Branch

A branch is an independent line of development within the same repository.

Imagine your main project as a river flowing forward. A branch is a tributary that splits off, follows its own path, and can later rejoin the main river – or be abandoned entirely if it doesn’t work out.

Branches let you try something experimental – a new feature engineering approach, a different model architecture, a refactored preprocessing pipeline – without touching your stable, working code. If the experiment succeeds, you merge the branch back. If it fails, you discard it with no damage done.

Remote

A remote is a copy of your repository stored somewhere else – typically on GitHub or GitLab.

Remotes serve two purposes: backup (your work survives if your laptop dies) and collaboration (others can access and contribute to the same repository). The two core operations are push (sending your local commits to the remote) and pull (retrieving changes from the remote).

The Commands You Actually Need

Here’s the complete minimal Git command set for data science – organized by what you’re trying to do, not by command category.

First-Time Setup

# Tell Git who you are (do this once)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Initialize a new repository in your current folder
git init

# OR: Clone an existing repository from GitHub
git clone https://github.com/username/repository-name.git

The Daily Workflow

This three-command sequence is the backbone of daily Git use. Run it at the end of every meaningful working session:

# Check what's changed since your last commit
git status

# Stage the files you want to include
git add filename.py       # Stage a specific file
git add .                 # Stage ALL changed files

# Commit with a descriptive message
git commit -m "Add efficiency factor feature to preprocessing pipeline"

# Push to GitHub as backup
git push origin main

git status is your orientation command – run it constantly. It tells you which files have changed, which are staged, and which aren’t tracked yet. git add . is convenient, but use it with awareness. Stage specific files when you want precise control over what goes into a commit.

The message after -m is your note to future self. Write it for the person who will be reading this history in three months wondering what changed and why.

Viewing and Navigating

# Compact history - one line per commit
git log --oneline

# See exactly what changed in a specific commit
git show abc1234

# See what the project looked like at a specific commit
git checkout abc1234

# Return to the present
git checkout main

# Restore a file to its last committed version
git restore filename.py

git log –oneline is where a well-maintained commit history earns its value. Compare:

a3f92b1 Update README
e91c4d2 Fix bug
b7a1203 Changes

vs.

a3f92b1 Retrain model with 6-month data window, improves F1 by 0.04
e91c4d2 Fix temperature outlier handling - replace -99 with NaN
b7a1203 Add HR drift and efficiency factor as derived features

The second history is a project diary. The first is nearly useless.

Working with Branches

# Create and switch to a new branch in one command
git checkout -b experiment-new-features

# List all branches
git branch

# Merge a branch back into main
git checkout main
git merge experiment-new-features

# Delete a branch after merging
git branch -d experiment-new-features

The branch workflow for data science is straightforward: create a branch for your experiment, commit freely, and merge back if it works. If it doesn’t – delete the branch, nothing was harmed. This pattern transforms risky experiments into safe ones.

The .gitignore File: What Not to Track

Not everything in your project folder should be tracked. A .gitignore file tells Git which files and folders to silently ignore. For data science projects:

# Data files (too large for Git, manage separately)
*.csv
*.xlsx
data/

# Model weights
*.pkl
*.h5
models/

# Python environment files
__pycache__/
venv/
.env

# OS files
.DS_Store

Create a file named .gitignore in your project root. Git will ignore everything listed there.

A note on data files: Large data files generally shouldn’t live in Git repositories – they bloat the history and slow everything down. Track your code in Git and manage your data separately, with the data loading path documented in your README. Tools like DVC (Data Version Control) exist for versioning large datasets if that becomes necessary.

A Practical Git Workflow for Data Science Projects

Here’s what a complete, sensible Git workflow looks like from project start to active experimentation.

Project Setup (Once)

# Initialize the project
mkdir cycling-performance-analysis
cd cycling-performance-analysis
git init

Create your .gitignore, a basic folder structure, and a README. Then make your first commit:

git add .gitignore README.md
git commit -m "Initial project structure"
git push origin main

A clean starting point. Everything from here is tracked.

Active Working Sessions

# Start of session: orient yourself
git status
git log --oneline

# End of session: commit and push
git add src/preprocessing.py
git commit -m "Add missing value handling for temperature column"
git push origin main

Pull at the start of each session if you work across multiple machines. Push at the end of every session as a backup. That’s the entire remote workflow for solo projects.

Running an Experiment

# Create a branch, work freely
git checkout -b try-gradient-boosting
git commit -m "Switch to gradient boosting - initial results"
git commit -m "Tune max_depth and learning_rate - F1 improves to 0.81"

# Success: merge back
git checkout main
git merge try-gradient-boosting
git branch -d try-gradient-boosting

# Failure: abandon cleanly
git checkout main
git branch -d try-gradient-boosting

Common Situations and How to Handle Them

“I committed something I shouldn’t have.”

# Undo the last commit but keep the changes staged
git reset --soft HEAD~1

“I want to see what changed between two commits.”

git diff abc1234 def5678

“I accidentally deleted a file and want it back.”

git restore deleted-file.py

“My branch and main have conflicting changes.”

A merge conflict occurs when two branches change the same part of the same file. Git marks the conflict directly in the file:

<<<<<<< HEAD

efficiency_factor = power / heart_rate

=======

efficiency_factor = (power / heart_rate) * 100

>>>>>>> experiment-branch

Resolve it by editing the file to keep the version you want, removing the conflict markers, then staging and committing. It looks intimidating the first time. It becomes routine quickly.

The Mindset Shift: Commits as a Lab Notebook

The most useful mental reframe for Git in data science is this: treat your commit history like a lab notebook.

A good lab notebook doesn’t just record results – it records what you tried, what you changed, what you observed, and why you made each decision. A researcher reading it six months later can reconstruct exactly what happened and why.

A good Git history does the same thing. Each commit message is a note to your future self.

Commit frequently. Write descriptive messages. Use branches for experiments. Push regularly for backup.

Do these four things consistently and Git transforms from an intimidating piece of infrastructure into something genuinely useful – a complete, navigable history of every analytical decision you’ve ever made on a project.

Summary: The Minimal Git Toolkit

Command	What It Does	When to Use It
git init	Initialize a repository	Once, at project start
git status	Check current state	Constantly
git add	Stage changes	Before every commit
git commit -m	Save a snapshot with message	After meaningful progress
git log –oneline	View commit history	When you need context
git checkout	Switch branches or navigate history	Experimenting or reviewing
git branch	Create or list branches	When starting experiments
git merge	Combine branches	When an experiment succeeds
git push	Send commits to remote	End of each session
git pull	Retrieve remote commits	Start of each session

What Comes Next

Once the basics are comfortable, two areas are worth exploring further:

GitHub as a collaboration platform – pull requests, code review, issues, and project management tools that make team data science work tractable.

DVC (Data Version Control) – a Git-compatible tool specifically designed for versioning large datasets and model artifacts, filling the gap that standard Git leaves open for data-heavy projects.

But those are depth additions. The commands above, used consistently, will handle the vast majority of real data science version control needs.

Stop naming files final_v2_ACTUALLY_FINAL.py. Start committing.