What Version Control Is

Version control is a system that records every change to a set of files over time, so you can recover any past state, see who changed what and why, and let several people work on the same code without overwriting each other. Without it, your history is a folder of report_final_v2_REAL_fixed.zip files and a Slack thread nobody can reconstruct.

That recovery-and-collaboration guarantee is the whole point. The tool stores not just the latest bytes but the full sequence of states that produced them, each labelled with an author, a time, and — if you do it right — a reason. Git is the version control system that won; the rest of this course is about using it deliberately rather than by superstition.

The Cost of No Version Control

Picture the alternative honestly. Backups are manual, so they are skipped under deadline. Two people edit the same file and reconcile it by emailing copies back and forth. A change breaks production and nobody can answer the only question that matters — what changed, and when — because the previous version was overwritten in place. Every one of these is a failure of memory, and version control exists to give a project a memory that does not depend on anyone's discipline.

The subtler cost is the one you feel six months later. A line of code looks wrong, you are about to delete it, and there is no record of why it was added. With version control that line carries its history: the commit that introduced it, the message explaining the bug it fixed, the change that shipped alongside it. Delete it now and you may reintroduce the exact bug it was written to prevent.

Centralized vs Distributed Models

Two designs dominate. A centralized system — Subversion, Perforce — keeps the single authoritative history on a server. To commit, view history, or branch, you talk to that server. A distributed system — Git, Mercurial — gives every clone the entire history. You commit, branch, diff, and read the log offline, then synchronize with others when you choose.

The practical consequences are large. In Git, committing on a plane is normal because the repository is on your disk, not behind a network call. Branching is nearly free because a branch is a pointer, not a server-side copy. The cost of the distributed model is symmetric: every clone holds the full history, which is exactly why a repository stuffed with large binaries becomes painful — everyone pays for every version forever.

What a Commit Records

A commit is not a diff in a mailbox. It records a complete snapshot of the tracked files at one moment, plus metadata: who made it, when, which commit it followed, and a message. The snapshot is what lets you restore any past state exactly; the parent link is what turns a pile of commits into a navigable history; the message is the part future-you actually reads.

That message is where most of the durable value lives, and it is the part most often wasted. "fix" tells you nothing in a month. A message that explains why the change was made — the bug, the constraint, the decision — turns the history into documentation that can never drift from the code, because it ships with it.

Git as the De Facto Standard

Git is not the only version control system, and it is not the friendliest. It won anyway. The overwhelming majority of new projects use it, which means the tooling, the hosting, the integrations, and the hiring pool all assume it. Learning Git well is no longer optional knowledge for a working engineer; it is the substrate everything else sits on.

That dominance is the practical reason to invest in the mental model rather than memorizing commands. The same Git concepts power GitHub, GitLab, your CI system, and your editor's source-control panel. Understand how Git stores history once, and every tool built on top of it stops being magic.