What version control actually is, and why Git specifically

Before branches and merges make sense, the one idea underneath all of Git — a project's history as a sequence of connected snapshots, not a single mutable folder — is worth getting straight first.

Beginner

4 min read

The problem before any version control tool existed

project_v1.py
project_v2.py
project_v2_FINAL.py
project_v2_FINAL_actually_final.py

Without a real system for tracking changes, "keeping history" usually meant manually copying files with new names, or emailing zip files back and forth — no reliable way to see exactly what changed between two versions, no way to safely try something risky and abandon it if it didn't work out, and genuine chaos the moment more than one person edited the same project. Version control is software specifically built to solve this: tracking every change to a set of files over time, in a structured, queryable way.

Git's core idea: commits are snapshots, not diffs

Commit A (add login page) -> Commit B (fix typo) -> Commit C (add logout button)

A common misconception is that Git stores a list of differences between versions — it actually stores a full snapshot of the entire project at each commit, though it's smart enough not to physically duplicate files that didn't change between commits. Each commit is a saved point in the project's history, with a message describing what changed and why, and a link back to the commit that came right before it — this chain of linked commits, each pointing to its parent, is the project's history, not a separate log kept alongside the files.

The three areas: working directory, staging area, and repository

Working directory  --git add-->  Staging area  --git commit-->  Repository (history)
(files you're        (changes you've           (permanently saved
 actually editing)     chosen to include          commits)
                        in the next commit)

This three-stage model is the single most important mental model for using Git day to day, and the part most confusing to someone new: editing a file only changes the working directory — nothing is tracked yet. git add moves specific changes into the staging area, explicitly choosing what will be included in the next commit (not everything that changed has to go in one commit together). git commit takes whatever's staged and permanently saves it as a new commit in the repository's history. This deliberate two-step (add, then commit) is what lets a commit be a clean, intentional snapshot — a chance to review exactly what's about to be saved — rather than automatically capturing every change the instant it happens.

Why Git specifically, among version control systems

Git is distributed — every clone of a repository has the entire history, not just the latest version, unlike older centralized systems where only one central server held the full history and everyone else had a thin, incomplete copy. This has real practical consequences: committing, viewing history, and creating branches (from the next lesson) all work entirely offline, since they only touch the local copy — no network round-trip needed until you actually want to share changes with somewhere else. It's also why Git handles branching and merging (genuinely core to how most teams use it day to day) efficiently enough to be a normal, constant part of the workflow, rather than a rare, heavyweight operation.

What a "repository" actually is

my-project/
  .git/          <- the entire history lives here, as ordinary files
  src/
  README.md

A Git repository is just a project folder with a hidden .git subfolder inside it — that hidden folder is the entire database of commits, branches, and history; the rest of the folder is the actual project files you see and edit normally. git init creates that .git folder in an existing project folder, turning it into a repository; there's no separate server or database required to start tracking history locally — everything Git needs lives right there, inside the project.

The habit this whole domain builds toward

None of Git's more advanced features — branching, merging, resolving conflicts, working with a remote host like GitHub — make sense without first internalizing this: history is a chain of deliberate, reviewed snapshots, built through the working-directory-to-staging-to-commit flow, stored entirely locally by default. Every later lesson in this domain builds directly on this same mental model, just adding one more capability on top of it at a time.