Recap — What Git Actually Stores

# What Git Actually Stores Most Git tutorials teach commands. They miss the mental model. Once you understand what Git actually stores, every command makes sense. ## Commits are snapshots, not diffs Other VCS (SVN, CVS) store the DIFFS between versions. Git stores SNAPSHOTS — the complete state of your project at each commit. ``` Commit A: file1.txt (v1), file2.txt (v1), file3.txt (v1) Commit B: file1.txt (v2), file2.txt (v1), file3.txt (v1) # only file1 changed; stored as snapshot Commit C: file1.txt (v2), file2.txt (v2), file3.txt (v1) ``` For unchanged files, Git stores a pointer to the previous content (deduplication). So it's space-efficient, but conceptually each commit IS a complete project state. Implication: Git operations work on whole snapshots, not on diffs. ## The three objects Git's object database has three types: ### 1. Blob — a file's content ``` SHA: e69de29bb... Content: "hello world" ``` Files are content-addressed by SHA-1 hash. Two files with identical content = same blob. ### 2. Tree — a directory listing ``` SHA: abc123... Content: 100644 blob e69de29bb... README.md 100644 blob ff8d3e7e2... app.py 040000 tree def456... src/ (subdirectory; another tree) ``` A tree maps filenames to blob/tree SHAs. Recursive structure for directories. ### 3. Commit — a snapshot + metadata ``` SHA: 7890ab... tree: abc123... (the root tree at this point) parent: 5678cd... (previous commit; can have multiple for merges) author: Alice date: 2026-05-26 message: "Fix login bug" ``` A commit points to one tree (the snapshot) + parent commit(s) + metadata. ## The DAG (Directed Acyclic Graph) Commits form a DAG via parent pointers: ``` A → B → C (main) \ D → E (feature) ``` - A is the root (no parent). - B's parent is A. - C's parent is B. - D's parent is C (forked from there). - E's parent is D. A merge commit has TWO parents: ``` A → B → C ────→ F (merge) \ / D → E ``` This DAG is the history. Most Git operations traverse it. ## Branches are just pointers A branch is a MOVABLE POINTER to a commit. That's it. ``` main → C (main points to commit C) feature → E (feature points to commit E) ``` `git branch new-branch` creates a new pointer to the current commit. No commits are copied. `git switch new-branch` (or `git checkout new-branch`) moves HEAD to that branch. When you commit, the current branch pointer moves forward. `HEAD` is a special pointer pointing to your current branch (or commit, if detached). ``` HEAD → main → C ``` ## Refs A "ref" is any name that points to a commit. Branches are refs. Tags are refs. `HEAD` is a ref. Stored in `.git/refs/` as files containing SHAs: ``` .git/refs/heads/main → 7890ab... (the main branch) .git/refs/heads/feature → cdef12... (the feature branch) .git/refs/tags/v1.0 → 7890ab... (the v1.0 tag) ``` ## Why this matters Once you see the DAG + refs picture, commands become obvious: - **commit**: create a new node; move current branch ref forward. - **branch**: create a new ref. - **merge**: combine two branches' commits; may create a merge commit (two parents). - **rebase**: replay commits from one branch onto another; creates new commits with different parents. - **reset**: move a ref to a different commit. - **checkout / switch**: move HEAD. Visualize the DAG; the command effects become clear. ## The three areas When you work with Git locally: ``` [Working tree] → [Staging area / Index] → [Repository (.git)] your files what's queued to commit permanent objects + refs ``` Flow: - Edit a file → working tree changes. - `git add` → stage changes (copies to index). - `git commit` → create a commit from staged state. ``` git status # On branch main # Changes not staged for commit: ← working tree changes # modified: app.py # Changes to be committed: ← staged changes # new file: README.md ``` `git add` is the staging step. `git commit` finalizes what's staged. ## Why is the staging area separate from "working tree"? It lets you: - Stage only some changes (`git add -p` for patch mode). - Commit logical chunks separately even if you edited multiple files. - Review what'll be committed (`git diff --staged`). ## The `.git/` directory ``` .git/ ├── HEAD # ref to current branch ├── refs/ # branches, tags, etc. ├── objects/ # blob/tree/commit content (SHA-addressed) ├── index # staging area ├── config # repo-local config └── hooks/ # scripts run at events ``` Everything is files. You can poke around. ## Common misconceptions 1. **"Git stores diffs."** It stores snapshots; diffs are computed on the fly. 2. **"Branches contain commits."** Branches POINT to one commit; commits exist independently in the object DB. 3. **"git checkout creates a branch."** No — `git branch` creates; `git checkout` moves to it. (`git checkout