Version control is software that records changes to files over time, usually as a sequence of snapshots you can name, compare, and restore. It is built for text (source code, configs, prose in plain formats) — not for giant binary blobs you replace wholesale every day, though people use it there too with tradeoffs.
When you hit Save in an editor, you overwrite one file. Version control adds a layer: you commit a bundle of changes with a message (“fix nav on mobile”, “add pricing table”). That commit becomes a permanent checkpoint you can return to later. The tool stores diffs — what lines changed — so you don’t need a full copy of the whole project every time.
When two people edit the same project, someone’s work will conflict. Version control gives rules: merge parallel lines of work, or mark conflicts so a human decides. Without it, “last save wins” silently deletes someone else’s work.
A branch is a parallel timeline of commits — try an experiment without breaking the main line. You’ll use branches constantly once you use Git; for now, the mental model is: version control = history + merges + branches.
Many tools exist. Git won the industry. The next module is Git-specific — but the ideas here apply to any serious version control system.