Gitastic
Path › Part 1: The mental model › Lesson 1 of 16
01

Commits are snapshots

The one idea everything else in git is built on.

1 Learn the idea

Most git confusion comes from memorising commands without a picture of what they do. So before any commands: what is git actually storing?

A commit has four things

  • A snapshot of every tracked file, exactly as it was at that moment (not a list of changes — git works out diffs later, on demand).
  • A message describing why this snapshot exists.
  • A parent pointer to the previous commit. Following parents backwards is your history.
  • An ID (hash) like a1b2c3d, calculated from all of the above. Change anything — even a comma — and you get a different ID.

2 Watch it happen

Watch a history grow

Press Play or use → to step through. Watch the graph as each command runs.

No commits yet — the history is empty.
Working directoryyour folder / editor
empty
git add →← git restore
Staging areathe next snapshot (index)
empty
git commit →← restore --staged
Repositoryno commits yet
empty
terminal · simulated, no real repository is touched
Read this demo as text
  1. $ git init

    An empty repository. Git is ready to take photos, but the album is empty.

  2. $ echo "# My Recipes" > README.md

    We create a file. It now exists in the working directory (your folder), but git is not tracking it yet.

  3. $ git add README.md

    git add puts the file into the staging area — "include this in the next photo".

  4. $ git commit -m "Start recipe book"

    Click! Our first commit appears. It has no parent: it is the root of history. Note its hash under the dot.

  5. $ echo "Pancakes: flour, milk, eggs" > pancakes.md
    $ git add pancakes.md

    A new file, staged for the next snapshot.

  6. $ git commit -m "Add pancakes"

    Second commit. The line to the left is its parent pointer — it remembers where it came from.

  7. $ edit pancakes.md "Pancakes: flour, milk, eggs, a pinch of salt"
    $ git commit -am "Salt the pancakes"

    commit -a stages every change to already-tracked files and commits in one go. Three snapshots now, each pointing to the previous one.

  8. $ git log --oneline

    git log walks the chain backwards from where you are. Newest first. The labels main and HEAD are pointers — that is the next lesson.

Myth
  • A commit stores the changes I made
  • History is a list of edits
  • Rewriting history edits old commits
Reality
  • A commit stores the full snapshot + a parent
  • History is a chain of snapshots
  • Commits are immutable; new ones get created
git initTurn the current folder into a repository
git add <file>Put a change into the next snapshot
git commit -m "msg"Take the snapshot
git log --onelineWalk history backwards from here

3 Check your understanding

Question 1

What does a commit fundamentally store?

Question 2

You fix a typo in the message of your last commit. What happens to its hash?

Question 3

How does git know the order of your history?

4 Practice for real

Your mission

Start your own history

Create a repository with 3 commits. Any files, any messages. End with a clean working tree.

No commits yet — the history is empty.
Working directoryyour folder / editor
empty
git add →← git restore
Staging areathe next snapshot (index)
empty
git commit →← restore --staged
Repositoryno commits yet
empty
terminal · simulated, no real repository is touched
Type commands below. `help` lists everything. Tab completes, ↑ recalls. Click a commit to paste its hash.
~/project (main) $