1.1. Why Version Control Exists
Every time you've kept multiple copies of a file "just in case," you were doing version control by hand — badly. Manual copies don't tell you what changed between versions, why it changed, or who changed it, and they multiply endlessly until nobody trusts which copy is current.
💡 First Principle: Version control isn't primarily about backup — it's about giving every change a timestamped, attributable, reversible record, so a project can move forward without anyone being afraid to make a change. Take away version control, and every edit becomes a small risk, because there's no reliable way to undo it or to know what else it might have broken.
Without it, teams fall back on file-naming conventions (final, final_v2, final_v2_USE_THIS) that break down the moment two people edit at once — one person's changes silently overwrite the other's, with no record that it happened. Version control replaces that guesswork with a system that tracks every change as a discrete, searchable event: who made it, when, and (if they wrote a good message) why.
This matters even outside teams. A solo developer benefits from the same safety net: the ability to revert a change that turned out to be a mistake, to see the exact history of how a file evolved, and to try something risky on a separate line of work without touching what already works.
⚠️ Exam Trap: Version control is not just a team collaboration feature. It's equally valuable for a single person working alone — the value is the history and the safety net, not the number of contributors.
Reflection Question: If two people edit the same file at the same time with no version control in place, what specifically goes wrong — and which part of that failure does version control fix?
