Why version control

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

The next lesson, Install and configure git, covers getting git running on your machine and introducing yourself to it.