Version Control with Git

Without version control, "which version of the strategy code produced this backtest" is answered with guesswork — a folder named strategy_final_v3_ACTUALLY_final.py and a hope that nobody edited it since. That is unacceptable when a research result has to be reproducible or a live trading bug has to be traced back to the exact code that ran. Git is a system for recording every change to a set of files as a permanent, timestamped snapshot, so the full history of a codebase — who changed what, when, and why — is always recoverable.

The idea: commits are snapshots, branches are pointers

A commit is a snapshot of the entire project at one moment, plus a message explaining the change and a link back to the commit before it — so the whole history is a chain. A branch is just a movable label pointing at one commit; creating a branch doesn't copy any files, it just lets you advance a second label independently while the first stays put. This is what makes parallel work possible: one researcher can branch off to try a new signal without touching what's running in production, and merge back in only once it's proven out.

git checkout -b feature/new-signal    # create and switch to a new branch
# ...edit files...
git add signal.py
git commit -m "Add mean-reversion overlay to signal.py"
git push origin feature/new-signal    # share the branch remotely
# open a pull request, get it reviewed, then merge into main

Worked example: tracing a bug to its commit

A live strategy started sizing positions incorrectly on March 3rd. git log shows every commit with its date and author; git blame position_sizer.py shows which commit last touched each line of that file.

git log --oneline --since="2024-02-28" --until="2024-03-04" -- position_sizer.py
# a1b2c3d  Feb 29  Refactor position sizing to use vol-target
# f9e8d7c  Feb 25  Add config flag for max leverage

a1b2c3d is the only commit touching that file in the window before the bug appeared — git show a1b2c3d displays exactly what changed, and git revert a1b2c3d creates a new commit that undoes it without erasing the record that it happened. This is the everyday version of version control's core value: the bug's root cause is a five-minute lookup, not an afternoon of guessing.

When two branches edit the same lines of the same file, git cannot pick a side automatically — this is a merge conflict, and git marks the file at the disputed lines and waits for a human to choose. It is not a sign of doing version control wrong; it is what's supposed to happen when two people legitimately changed the same thing, and resolving it means reading both versions and deciding what the merged code should actually say, then committing that decision.

Where it shows up

Version control fluency is assumed rather than explicitly tested in most quant-dev interviews, but expect a "walk me through your workflow" question, and expect it to surface indirectly in take-home assignments graded partly on commit history — small, well-described commits read as more competent than one giant commit dumped at the deadline.

On the job, every research or trading codebase lives in git: pull requests gate what reaches production (see Branching Strategies and Code Review), CI runs the test suite on every commit (see Continuous Integration Pipelines), and the commit hash that produced a given backtest or a given day's live trades is recorded alongside the results — this is what makes a research result reproducible and a trading incident debuggable months later.