Version control records changes to selected files over time so you can inspect, compare and recover earlier versions. In quant work, it helps answer a concrete question: did a valuation change because someone revised the model code or its saved assumptions? The record gives you versions to investigate; it does not establish that either version is financially correct.
Keep the earlier assumption
Suppose a fictional valuation project stores a decimal rate in
risk-config.json. An earlier saved state, labelled C0, contains 0.05. A later saved state, C1, contains 0.04. A comparison exposes the changed input, while the earlier state remains available for inspection. Keeping only the latest file would lose that evidence.
The later configuration adds a saved state without overwriting the earlier one. C0 and C1 are diagram labels, not Git object IDs; the rates are fictional decimal inputs.
The change history can carry a reason as well as content: for example, “revise the scenario rate.” That explanation helps a reviewer distinguish an intentional assumption change from an accidental edit. It is still a statement to review, rather than proof that the new rate is appropriate.
Git makes the history explicit
Git is a widely used distributed version-control system. A Git commit records a selected snapshot with metadata and links into the project's history. Editing a working file alone does not create that record. In the usual staging workflow, you select and review the content that will enter the next commit.
These related actions have different roles:
| Action or facility | What it provides |
|---|---|
| Save a working file | Keeps the current edit on disk; it need not preserve its predecessor. |
| Commit locally | Records the selected version in the local repository. No remote connection is required. |
| Share through another repository | Transfers history so colleagues can obtain and review it. A local commit is not automatically shared. |
| Maintain backups | Protects against loss of the storage holding the work. Local history on a failed disk is not a separate backup. |
A repository stores the version history. Git can compare revisions and support separate lines of development that collaborators later combine. Combining changes may require a human to resolve conflicts and check the result. A hosting service adds a place to exchange work and review it; Git's local history does not depend on using a particular host. See Pro Git's discussion of remotes for that sharing boundary.
A code revision is only part of a run
History covers the files whose content was actually recorded. An untracked file, a later uncommitted edit or an externally refreshed market-data file is not recovered merely by selecting an old commit. An ignore rule also does not remove a file already tracked, as the Git ignore documentation explains.
Keep credentials out of project history. Record a usable identifier for external data and preserve the corresponding bytes under an appropriate data-retention process. Record the interpreter, packages, configuration and command needed for a reproducible environment. Versioning a dependency file records that file; it does not preserve every installed package, operating-system dependency or external input automatically.
For a practical next step, the SelfMadeQuant Git lesson walks through reviewing and recording a focused change. Its public preview is open; the full lesson requires membership.
Sources
- Pro Git, About Version Control: recalling versions, comparing changes and the distinction between local and distributed systems.
- Pro Git, What is Git?: snapshots, local operations and modified, staged and committed states.
- Pro Git, Working with Remotes: sharing history between repositories.
- Git, gitignore: ignore rules apply to intentionally untracked files.