Git and Version Control: The Developer's Safety Net

Why Version Control Is Non-Negotiable

Imagine you are working on a pricing model. It has been running in production for months. A colleague makes a "small fix" on Friday afternoon. Monday morning, the model is producing wrong prices and nobody can figure out what changed.

Without version control, you are searching through backup folders and asking people what they remember. With Git, you run git log and see exactly what changed, who changed it, and when. You can revert the change in seconds.

In regulated financial environments, this is not just convenient — it is often required. Audit trails, change control, and the ability to demonstrate exactly what code was running at any point in time are regulatory expectations.

---

The Mental Model

Git tracks changes to files over time. Think of it as an unlimited undo system that also lets multiple people work on the same codebase without overwriting each other's work.

The core concepts:

• Repository — a project folder that Git is tracking
• Commit — a snapshot of all tracked files at a point in time, with a message describing what changed
• Branch — a parallel line of development (like making a copy of the project to experiment on)
• Merge — combining changes from one branch into another
• Remote — a copy of the repository hosted elsewhere (GitHub, GitLab, Bitbucket)

The Basic Workflow

# See what has changed
git status

# Stage specific files for commit
git add pricing_model.py
git add tests/test_pricing.py

# Commit with a meaningful message
git commit -m "Fix off-by-one error in day count calculation"

# Push to the remote repository
git push origin main

Every commit creates a permanent record. Six months from now, you can see exactly what this change was, read the message explaining why, and view the full diff of every line that changed.

---

Branching: Work Without Fear

Branches are where Git becomes genuinely powerful. Instead of making changes directly to the main codebase, you create a branch, do your work there, and merge it back when it is ready.

# Create a new branch for your feature
git checkout -b feature/new-risk-model

# ... make changes, commit as you go ...
git add .
git commit -m "Add initial risk model implementation"

git add .
git commit -m "Add unit tests for risk calculations"

# Push the branch to remote
git push origin feature/new-risk-model

This means the main branch always has working code. Your in-progress work lives on a separate branch where it cannot break anything. If the feature turns out to be a bad idea, you just delete the branch — no harm done.

Pull Requests / Merge Requests

In professional teams, you do not merge your own branches. You open a pull request (GitHub) or merge request (GitLab) and a colleague reviews your code before it is merged. This catches bugs, spreads knowledge across the team, and creates a discussion record for every change.

For trading systems, code review is particularly important. A misplaced decimal point in a risk calculation is the kind of bug that a second pair of eyes catches but automated tests might miss.

---

Commit Messages That Actually Help

Bad commit messages are depressingly common:

"fix"
"update"
"WIP"
"stuff"
"changes"

Good commit messages tell future-you (and your colleagues) what changed and why:

"Fix VWAP calculation: exclude cancelled orders from volume"
"Add circuit breaker for market data feed failures"
"Refactor position aggregation to handle multi-currency portfolios"
"Update margin requirements per new regulatory guidance (REG-2024-15)"

The convention is: start with an imperative verb, keep the first line under 72 characters, and add a longer description below if needed.

---

Common Git Operations

Viewing History

# Recent commits
git log --oneline -20

# What changed in a specific commit
git show abc1234

# Who last modified each line of a file
git blame pricing_model.py

# Search commit messages
git log --grep="VWAP"

# See all changes to a specific file over time
git log --follow -p -- pricing_model.py

git blame is invaluable when debugging — it tells you exactly when each line was last changed and by whom. Combined with good commit messages, it often explains why the code is the way it is.

Undoing Mistakes

# Discard uncommitted changes to a file
git checkout -- pricing_model.py

# Unstage a file (keep changes, just remove from staging)
git reset HEAD pricing_model.py

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

# Completely undo the last commit and discard changes
git reset --hard HEAD~1

Stashing: Temporary Shelving

# Save current work temporarily
git stash

# Do something else (switch branches, pull updates, etc.)
git checkout main
git pull

# Come back and restore your work
git checkout feature/new-risk-model
git stash pop

---

.gitignore: What Not to Track

Not everything belongs in version control. API keys, compiled files, large data files, and local configuration should be excluded:

# .gitignore
__pycache__/
*.pyc
.env
.env.local
*.csv
*.parquet
data/
secrets/
node_modules/
.vscode/

In finance, accidentally committing API keys or credentials to a repository is a serious security incident. Your .gitignore is a first line of defence — but see our guide on security and authentication for a more complete picture.

---

Git in the Bigger Picture

Git is the foundation that makes CI/CD pipelines possible — automated tests run when you push, deployments trigger on merge to main. It enables the SDLC practices that professional teams rely on. And it integrates with code review, issue tracking, and project management tools that coordinate team efforts.

Learning Git's basics takes a day. Getting comfortable enough to branch, merge, resolve conflicts, and navigate history with confidence takes a few weeks of regular use. It is an investment that pays off immediately and compounds over your entire career.