How Git actually thinks

You've used Git (add, commit, push) — but to use it confidently (and fix mistakes), you need to understand how Git actually thinks. Git isn't magic — it's a simple, elegant model of snapshots and pointers. Let's build the right mental model.

Git tracks snapshots, not files

# Git's core idea: each COMMIT is a SNAPSHOT of your ENTIRE project at
# a moment in time (not a "diff" — a full picture).

# A commit records:
# - A snapshot of all your tracked files.
# - A pointer to the PARENT commit(s) (the previous snapshot).
# - Metadata (author, message, timestamp).
# - A unique HASH (id) like a1b2c3d...

# So your project's history is a CHAIN of snapshots:
#   commit1 <- commit2 <- commit3 <- ... (each points to its parent)

# Understanding this — commits are snapshots linked by parent pointers —
# demystifies EVERYTHING else in Git.

Git's core idea: each commit is a SNAPSHOT of your ENTIRE project at a moment in time (not a "diff" — a full picture). A commit records: a snapshot of all your tracked files, a pointer to the PARENT commit(s) (the previous snapshot), metadata (author, message, timestamp), and a unique HASH (id) like a1b2c3d.... So your project's history is a CHAIN of snapshots: commit1 ← commit2 ← commit3 ← ... (each points to its parent). Understanding this — commits are snapshots linked by parent pointers — demystifies EVERYTHING else in Git. This is the fundamental insight: Git history is a chain of snapshots (commits), each linked to its parent. A branch is just a pointer to a commit (below). Once you see Git this way — snapshots + pointers — the commands (branch, merge, reset, etc.) become logical (they move pointers and combine snapshots). This mental model is worth internalizing — it turns Git from mysterious into understandable.

The three areas

# Git has three "areas" your files move through:

#   WORKING DIRECTORY  ->  STAGING AREA  ->  REPOSITORY (.git)
#   (your files)          (git add)         (git commit)

# - WORKING DIRECTORY: your actual files (where you edit).
# - STAGING AREA (index): what you've marked to go in the NEXT commit
#     (git add moves changes here — you choose WHAT to commit).
# - REPOSITORY: the committed history (git commit saves the staged
#     snapshot permanently).

git status           # shows what's modified, staged, untracked
git add file.txt     # stage a change (working dir -> staging)
git add .            # stage everything
git commit -m "msg"  # commit staged changes (staging -> repository)

# The staging area lets you craft PRECISE commits (choose exactly what
# goes in each one) — a Git superpower.

Git has three "areas" your files move through: WORKING DIRECTORY → STAGING AREA → REPOSITORY (git add → git commit). The WORKING DIRECTORY is your actual files (where you edit); the STAGING AREA (index) is what you've marked to go in the NEXT commit (git add moves changes here — you choose WHAT to commit); the REPOSITORY is the committed history (git commit saves the staged snapshot permanently). git status (shows modified/staged/untracked), git add file.txt (stage — working → staging), git add . (stage everything), git commit -m "msg" (commit staged — staging → repository). The staging area lets you craft PRECISE commits (choose exactly what goes in each one) — a Git superpower. This three-area model clarifies the workflow: you edit (working dir), stage what you want (git add → staging), then commit (staging → repository). The staging area is often confusing to beginners, but it's powerful: it lets you build a commit deliberately (staging some changes, not others). Understanding the three areas (and how add/commit move between them) makes the basic Git workflow clear.

Branches and HEAD are just pointers

# A BRANCH is just a POINTER to a commit. HEAD points to your current
# branch/commit. That's it.

git branch                 # list branches (* = current)
git log --oneline          # see the commit history (hashes + messages)
git log --graph --oneline --all   # visualize branches + history

# When you commit, the current branch pointer MOVES FORWARD to the new
# commit. When you create a branch, you just make a new pointer.

# main    -> commit C
# feature -> commit C  (a new branch = a new pointer to the same commit)
# ...you commit on feature -> feature moves to D, main stays at C.

# This is why branching in Git is FAST + cheap: a branch is just a
# lightweight pointer (not a copy of your files). Understanding "branches
# = pointers, commits = snapshots" is the KEY mental model.

A branch is just a POINTER to a commit. HEAD points to your current branch/commit. That's it. git branch (list branches — * = current), git log --oneline (see the commit history — hashes + messages), git log --graph --oneline --all (visualize branches + history). When you commit, the current branch pointer MOVES FORWARD to the new commit. When you create a branch, you just make a new pointer. So: main → commit C, feature → commit C (a new branch = a new pointer to the same commit); you commit on feature → feature moves to D, main stays at C. This is why branching in Git is FAST + cheap: a branch is just a lightweight pointer (not a copy of your files). Understanding "branches = pointers, commits = snapshots" is the KEY mental model. This completes the model: commits are snapshots (linked by parents), and branches are movable pointers to commits. Creating a branch is instant (just a new pointer); committing moves the current branch's pointer forward. This is why Git branching is so cheap and fast (unlike older systems that copied files). Grasping this — branches and HEAD are pointers, commits are snapshots — makes everything (merging, resetting, etc.) logical.

The mistake beginners make

Not understanding the model (treating Git commands as magic incantations — then fearing mistakes). Also, confusing the three areas (working dir vs staging vs repo — what add/commit do). Thinking branches copy files (they're just pointers — cheap). And fearing Git (understanding the model makes it predictable). Understand how Git actually thinks: commits are SNAPSHOTS of your whole project (linked by parent pointers — history is a chain), files move through three areas (working dir → staging → repository, via add/commit — the staging area lets you craft precise commits), and branches (and HEAD) are just POINTERS to commits (so branching is cheap/fast — a pointer, not a copy). This model — snapshots + pointers + three areas — demystifies Git. Once you see it this way, the commands become logical (they move pointers, combine snapshots, shuffle the areas). Understanding the model is what makes you confident with Git (and able to fix mistakes). Build the right mental model first.

Your turn

# Explore Git's model:
git status                    # see the three areas' state
git log --oneline             # the chain of commits (snapshots)
git log --graph --oneline --all   # visualize branches (pointers)

# Watch the three areas:
echo "test" > file.txt
git status                    # file.txt is UNTRACKED (working dir)
git add file.txt              # stage it (-> staging area)
git status                    # now STAGED (green)
git commit -m "add file"      # commit (-> repository)
git log --oneline             # your new commit (snapshot) in the chain

# Branches are pointers:
git branch feature            # create a pointer to the current commit
git branch                    # see both (main + feature point to same commit)

# Mental model: commits = snapshots (linked by parents); branches/HEAD =
# pointers; three areas (working -> staging -> repo). This makes Git make
# sense.

---

Your turn

1. Understand commits are SNAPSHOTS of your entire project (not diffs), linked by parent pointers — your history is a chain of snapshots.
2. Understand the three areas: working directory (your files) -> staging area (git add — what goes in the next commit, for precise commits) -> repository (git commit — saved history).
3. Understand branches (and HEAD) are just POINTERS to commits — so branching is cheap/fast (a pointer, not a copy); committing moves the current branch's pointer forward.

Key points

• Each commit is a SNAPSHOT of your entire project (not a diff) + a pointer to its parent(s) + metadata + a hash — your history is a chain of snapshots linked by parent pointers.
• Files move through three areas: working directory (your files) -> staging area/index (git add — what you've marked for the next commit) -> repository (git commit — permanent history); staging lets you craft precise commits.
• A branch is just a POINTER to a commit; HEAD points to your current branch/commit — committing moves the current branch's pointer forward, creating a branch just makes a new pointer.
• This is why branching is fast/cheap (a lightweight pointer, not a file copy) — the mental model (snapshots + pointers + three areas) demystifies all of Git and makes you confident.