What Git actually is (not just 'save button 2.0')

Most people learn Git as a list of commands to memorize: add, commit, push. That gets you through a tutorial, but it falls apart the moment something goes wrong — and with Git, something always eventually goes wrong. This lesson is the ten minutes of mental model that would have saved you hours of panicked Googling later.

Git thinks in snapshots, not diffs

A lot of people assume Git stores a list of changes — "line 12 changed from X to Y." It doesn't. Every commit is a full snapshot of your entire project at that moment (Git is smart about not literally duplicating unchanged files on disk, but conceptually, think "snapshot," not "diff"). That's why Git can do things like check out an old commit instantly, or compare any two points in history directly — it's not replaying a chain of edits, it's just looking at two complete snapshots side by side.

Three places your work can be

At any moment, a file in your project lives in up to three places:

1. Working directory — the actual files on disk, what your editor shows you.
2. Staging area (the "index") — a draft of what your next commit will contain. This is what git add does: it doesn't save your work, it marks "include this version of this file in the next snapshot."
3. Repository — the permanent history of committed snapshots. This is what git commit does: it takes whatever is staged and seals it into a new snapshot, permanently.

This is why git add feels like a weird extra step to beginners coming from "just save the file" tools — it exists so you can build a commit deliberately, staging exactly the changes that belong together, even if your working directory currently has a mix of finished and half-finished edits.

Commits form a chain, not a list

Each commit points to the commit that came before it. Follow those pointers backward and you get your project's entire history — a chain (technically a graph, once branches enter the picture, which the next lesson covers). A branch is just a movable label pointing at one commit in that chain. That's the whole trick behind how cheap and fast branching is in Git, compared to some older version control tools: creating a branch doesn't copy anything, it just adds a new label.

Keep this picture in your head — working directory → staging → repository, and commits as a chain of snapshots — and the rest of Git stops being a memorized incantation and starts being predictable.