Version control foundations — snapshots, history, and auditability

Version control is the substrate under every other practice in this course. CI pipelines, GitOps controllers, signed tags, signed artifacts, and auditable change history all depend on a working version-control repository. Get this wrong and everything downstream loses its meaning: a CI run that cannot point at a commit is a CI run that cannot be reproduced, and a deployment that cannot point at an artifact is a deployment that cannot be trusted.

What version control solves

A version-control system is a system that records changes to a set of files over time so that a specific version can be recalled later. The word specific matters: the point is not just “I have my code” but “I can recover the exact state at 14:23 on Tuesday when build #4527 produced artifact v3.2.7 from commit 8a3f9d2”.

flowchart LR
    A[Working change] -->|commit| B[Snapshot]
    B --> C[Repository history]
    C --> D[Recalled version]
    C --> E[Audit trail]
    C --> F[Collaboration merge]
    C --> G[Reproducible build]

The four operational properties version control gives an infrastructure team are:

• History. Every change is recorded with author, timestamp, parent commit, and a message. The repository never forgets, even when the engineer who made the change has left.
• Collaboration. Multiple engineers can work on the same set of files concurrently. The system resolves their changes and surfaces the conflicts it cannot.
• Reproducibility. Given a commit reference, the exact bytes of the repository at that moment can be reconstructed. Given those bytes and a build pipeline, the exact artifact can be reproduced.
• Auditability. A change in production can be traced back to a commit, that commit can be traced back to a pull request, and that pull request can be traced back to a reviewer and a rationale.

Snapshot versus lock

The two historical models for version control are lock-based and snapshot-based. Lock-based systems (CVS, early Subversion with file locks) serialise edits: only one engineer can change a file at a time. Snapshot-based systems (Git, Mercurial) record the entire state of the repository at each commit and merge concurrent changes when they happen.

The operational difference:

• Lock-based produces no merge conflicts because concurrent edits are impossible, but it serialises engineers and produces commits that change one thing at a time.
• Snapshot-based allows concurrent edits and merges them automatically when possible, surfacing conflicts only when the system cannot resolve them. The repository history reflects what actually happened, not a serialised fiction.

Git is snapshot-based. A commit in Git does not record a diff; it records the complete tree of files at that moment, identified by the SHA-256 hash of its contents (or SHA-1, historically). The diff between two commits is computed by the system when needed.

Why infrastructure code lives in version control

The arguments that justify version control for application code - collaboration, history, rollback - apply with extra force to infrastructure code:

• Terraform state without version control is unrecoverable. A state file in someone’s laptop is a state file that does not exist when that laptop fails.
• Ansible playbooks without history cannot be audited. Six months after an incident, the question is “what changed?” and the answer is “look at the commit history”.
• Kubernetes manifests without review are YAML diffs applied by whoever has cluster access. Branch protection and required reviewers are the only mechanism that prevents a single careless commit from changing production.
• Container image references without pinning are mutable. A latest tag is a contract that resolves to whatever someone pushed most recently. Version control lets you pin by digest and promote the same digest across environments.

What this course assumes

You should be comfortable on a Linux command line and have edited configuration files and run shell commands against production systems. You should not need to know Git in depth - that is what Parts II through VI teach. But you should understand the purpose of what you are about to learn: every command in the rest of this course is in service of one or more of the four properties above.

Production discipline

The production framing of version control has three rules that will recur throughout this course:

1. Commits are cheap; lost commits are expensive. If a change is worth making, it is worth committing. Working outside of version control “just for now” is how production changes become unauditable.
2. History is forever. What you commit now will exist in your repository for years. Write commit messages for the engineer who reads them in three years - that engineer might be you.
3. The default branch is sacred. Whatever branch your team treats as the trunk - main, master, production - is the branch the production system is built from. Direct commits to the default branch are forbidden in any serious infrastructure repository; every change goes through a pull request.

Cross-course references

• Linux for Production Sysadmins - Parts XII (RepoSecurity) and XXXIV (ConfigMgmt) cover apt/dnf repository trust, which is the Linux-system-level analogue of Git repository trust.
• Ansible for Production Sysadmins - Part XXXVII (RepoArch) covers Ansible repository architecture; the patterns are shared.
• Terraform for Production Sysadmins - Parts IX-XII (State) cover Terraform state, which is the most important argument for version-controlling infrastructure.

Quiz