Why Version Control?
You've seen this folder before: report.docx, report_v2.docx,
report_v2_final.docx, report_v2_FINAL_actually_final.docx. Nobody
remembers what changed between them, which one the client approved, or whether it's safe to
delete the other three. Now imagine that mess, but it's source code, three people are editing it
at once, and a bug shipped to production last Tuesday. That's the problem
version control — and specifically Git — exists to solve.
💡 The Bottom Line
Git is a tool that records snapshots of your project over time, so you always know exactly what changed, when, why, and by whom — and you can jump to, compare, or undo any of those snapshots on demand. It turns "I hope this doesn't break anything" into "if it breaks, I can go back in ten seconds."
The "final_v2_FINAL" problem
Filename-based versioning fails for reasons that get worse as a project grows:
- No real history — a filename tells you a file is "newer," not what actually changed inside it.
- No safe collaboration — if two people edit the same file, someone's changes get overwritten unless they're extremely careful (or lucky).
- No accountability — when something breaks, there's no record of who changed what, or why.
- No easy undo — "go back to how it was on Tuesday" means digging through whatever copies you happened to save, if any.
Git replaces all of that with one project history that every collaborator shares.
Snapshots, not diffs
A common misconception is that Git stores a list of line-by-line changes, like a stack of patches. It doesn't. Every time you save your work with Git (a commit), Git stores a full snapshot of every tracked file at that moment — but it's smart about it: files that haven't changed since the last commit are just referenced, not duplicated, so snapshots stay small and fast even in huge projects.
Thinking in snapshots is the key mental shift. A commit isn't "the changes I made" — it's "here is the complete, working state of the project at this exact point in time." That's what makes jumping between commits, comparing them, or rolling back to one so reliable.
🙋 There Are No Dumb Questions
Q: Isn't Git the same thing as GitHub?
A: No, and this trips up almost everyone at first. Git is the version
control tool itself — it runs entirely on your computer and works with zero internet
connection. GitHub (and GitLab, Bitbucket, etc.) is a website that hosts
Git repositories in the cloud so people can share and collaborate on them. You could use Git
for years and never touch GitHub. Lesson 5 covers remotes like GitHub in detail.
Why every serious project uses it
Once a project has more than one contributor, or lives longer than an afternoon, version control stops being optional:
- Fearless experimentation — you can try a risky change knowing you can always get back to the last working state.
- Parallel work — multiple people (or multiple features) can be developed at once without stepping on each other, via branches (Lesson 3).
- A complete audit trail — every change has an author, a timestamp, and a message explaining why it was made.
- Disaster recovery — your laptop dying doesn't mean losing the project's history, once it's backed up to a remote (Lesson 5).
⚠️ Watch Out
Git is not a substitute for backups of things it wasn't designed to track — huge binary files, database dumps, secrets, or your entire hard drive. Git shines at tracking text-based source code where it can meaningfully show you what changed. Trying to commit gigabytes of video files or credentials into a Git repo is a common early mistake.
🔧 Try It Yourself
Open a terminal and check whether Git is already installed:
git --versionIf you see a version number, you're ready for the next lesson. If not, install Git from
git-scm.com for your operating system, then run the command again to confirm.
No project needed yet — just confirm the tool is there.
✅ Quick Check
What does a Git commit actually store?
Next up: how you actually get files into that history — staging, committing, and reading the log Git keeps for you.