Why version control

Whatever brought you here — a team that keeps clobbering each other’s work, or a solo project drowning in zip files — that question is the one Git was built to answer. Before a single command, it is worth seeing the problem clearly, because every command in this section is just a precise answer to some piece of it.

The folder that haunts every solo project

You have been there. A project folder that looks like this:

project/
  final.zip
  final_v2.zip
  final_v2_FINAL.zip
  final_v2_FINAL_actually_final.zip
  backup_before_i_broke_everything.zip

This is manual version control. It is painful, it does not scale past one person, and the moment a teammate emails you their copy of final_v2.zip, you have a merge conflict you have to resolve by reading two files side by side and guessing.

Git was built to solve exactly this problem — for teams of hundreds working on millions of lines of code — but it solves the solo case just as elegantly.

Git as a time machine

The core idea is simple: instead of saving a new zip file when something works, you take a commit (a named save point). A commit is a snapshot of every file in your project at that moment, paired with:

• a short message you write (“Add login form validation”)
• your name and email
• a timestamp
• a unique ID (a long hex string like a3f8c12)

That snapshot is permanent and tamper-evident. You can jump back to any commit in history and see your project exactly as it was, or ask “who changed this line and why?”

Snapshots, not diffs

A detail that matters: git stores a full snapshot of every tracked file at each commit — not just the lines that changed. This makes operations like “restore project to C2” instant and independent of history length. (Internally git deduplicates unchanged files, so storage stays efficient, but the logical model is always a complete picture of the project.)

This is different from older systems like SVN, which stored only incremental diffs. Full snapshots mean you never have to replay a chain of patches just to see what a file looked like two months ago.

Distributed: every clone is a full backup

Git is distributed, meaning when you clone a repository (the folder where git stores all commits and history), you get the entire history locally — not just the latest version. You can commit, browse history, create branches, and work entirely offline.

There is no single server that “owns” the truth. Services like GitHub or GitLab are just well-known places to push a copy so teammates can pull from it. If that server disappeared tomorrow, every developer who ever cloned the repo would still have the full history.

How a team works in parallel

Here is the 30-second mental model of day-to-day team work:

1. Each engineer clones the shared repository. They each have a full copy.
2. An engineer creates a branch — a lightweight pointer to a diverging line of commits — so their work-in-progress does not touch anyone else’s code.
3. They commit to their branch as often as they like. Commits are cheap and local; they cost nothing until pushed.
4. When the work is ready, they open a pull request: a proposal to merge their branch back into the shared main branch. Teammates review the diff, leave comments, and approve.
5. The branch merges. Everyone pulls the updated main branch. The cycle repeats.

Nobody emails zip files. Nobody overwrites anyone’s work. And if the merged feature turns out to be broken, the team can revert that merge commit — a single operation — and the codebase is exactly as it was before.

Jargon in one place

In one breath

Version control replaces the folder of final_v2_FINAL.zip files with one project whose entire history is recorded as commits — named snapshots of every tracked file, each carrying a message, an author, a timestamp, and a unique ID. Git is distributed, so every clone holds the complete history and works offline; GitHub is just a convenient place to share a copy, not the keeper of truth. Teams stay out of each other’s way by committing on branches and merging them back, and because every commit is a permanent save point, undoing even a three-week-old mistake is one operation, not an archaeology dig.

Practice

Before the quiz, picture the failure mode Git prevents: two teammates both start from report.py, each edits it all day, then each emails the other their copy. Without version control, what exactly is lost when one file overwrites the other — and which two terms from the jargon table turn that collision from a catastrophe into a routine, reviewable merge?

A question to carry forward

You now know why version control exists and the vocabulary it runs on — commit, branch, clone, distributed. But every one of those is still just an idea on a timeline diagram. None of it does anything until Git is running on your machine and knows who you are — because, remember, every commit is stamped with an author and email, and Git cannot stamp what you have not told it. So the first practical step is the smallest one: install Git, and introduce yourself to it, so your name lands on every snapshot you make. That is the next lesson.