Why Version Control (and Why Git Specifically)

In one line

Version control is a complete, searchable history of every change ever made to a project, with the ability to go back to any point — Git specifically won because it's distributed, fast, and free.

0/5 · 0%

Think of it like this

Imagine writing a document with 'Save As' every single time you make a change — essay_final.docx, essay_final_v2.docx, essay_FINAL_ACTUAL.docx — and then trying to figure out which version had that one good paragraph you deleted three edits ago. Version control is exactly the tool built to make that mess unnecessary, for code specifically.

Key ideas

01
A version control system records every change to a set of files over time, who made it, when, and why (via a commit message) — and lets you view, compare, or restore any previous state instantly. Without it, 'undo' only goes back as far as your editor's session; with it, 'undo' goes back to the literal beginning of the project, forever.
02
Git is DISTRIBUTED — every clone of a repository is a complete copy of the ENTIRE history, not just the latest snapshot. This is the key difference from older CENTRALIZED systems (like Subversion/CVS) that kept one single master copy on a server: with Git, you can commit, branch, and view full history completely offline, and there's no single point of failure — anyone's clone can restore the entire project if the original server is lost.
03
Git was created in 2005 by Linus Torvalds specifically to manage the Linux kernel's source code — a project with thousands of contributors — after the tool they'd been using revoked their free license. This origin story explains a lot about Git's design: it's built for speed and integrity at massive scale, not for being the friendliest tool to learn on day one.
04
Nearly all modern software collaboration is built on top of Git: GitHub, GitLab, and Bitbucket are all just hosting services and social layers ON TOP of Git — the underlying version control engine is the same Git you run locally. Learning Git itself, not just 'GitHub,' is what actually transfers between every one of these platforms.
05
The one-sentence pitch you should be able to give in an interview: 'Git is a distributed version control system — every clone has the full history, which makes branching, offline work, and collaboration at scale possible in ways centralized systems never could.'

Code & diagrams

check-git-installed.shmarkdown

Confirm Git is installed and see its version before anything else.

# Check Git is installed
git --version

# See a short built-in help summary
git help -a | head -20

Explain it without notes

What's the practical difference between a centralized version control system and a distributed one like Git?

Why does 'every clone has the full history' matter in practice, beyond just being a neat technical fact?

Practice

Run git --version on your own machine and confirm you have a reasonably recent version installed (2.30+ is a reasonable baseline for everything in this course).

Think of (or search for) one real, concrete incident — your own or a well-known one — where having full project history saved someone from a serious mistake, and be ready to explain it in one sentence.

Trade-offs

↔
Git's distributed model is what makes offline work and resilience possible, but it does mean history itself can grow large over time (every clone carries the WHOLE history, not just the latest state) — for projects with genuinely huge binary assets, this is exactly the problem Git LFS (Phase 7) exists to solve, by keeping large files out of the core history.

Done when you can

I can explain what version control is and why it matters, without referencing Git specifically.
I understand the practical difference between centralized and distributed version control.
I have Git installed and confirmed the version on my own machine.