Git mental model (snapshots not diffs) - Step-by-Step Execution

Process Flow - Git mental model (snapshots not diffs)

Start: Working Directory

↓

Create Snapshot of Files

↓

Store Snapshot as Commit

↓

Link Commits in Chain

↓

Checkout Commit to Restore Files

↓

Modify Files -> New Snapshot

↓

Repeat

Git saves the whole state of your files as snapshots in commits, not just changes. Each commit stores a full picture of your project at that time.

Execution Sample

Git

git add .
git commit -m "Save snapshot"
git checkout HEAD~1

Add all files, save a snapshot as a commit, then go back to the previous snapshot.

Process Table

Step	Action	Files State	Commit Created	Commit Chain
1	Start with files in working directory	Files A, B, C (current content)	No	No commits yet
2	git add .	Files staged for commit	No	No commits yet
3	git commit -m "Save snapshot"	Files saved as snapshot	Commit 1 created	Commit 1 (root)
4	Modify File B	File B changed in working directory	No	Commit 1
5	git add .	Files staged for commit	No	Commit 1
6	git commit -m "Save snapshot 2"	Files saved as snapshot	Commit 2 created	Commit 1 -> Commit 2
7	git checkout HEAD~1	Files restored to Commit 1 state	No	Commit 1 -> Commit 2 (HEAD detached)
8	End	Files at Commit 1 snapshot	No	Commit 1 -> Commit 2 (HEAD detached)

💡 Checked out previous commit snapshot, HEAD detached at Commit 1

Status Tracker

Variable	Start	After Step 3	After Step 6	After Step 7
Working Directory Files	A,B,C original	A,B,C snapshot 1	A,B modified,C snapshot 2	A,B,C snapshot 1 restored
Commit Chain	None	Commit 1	Commit 1 -> Commit 2	Commit 1 -> Commit 2 (HEAD detached)
HEAD Pointer	None	Commit 1	Commit 2	Commit 1 (detached)

Key Moments - 3 Insights

Why does Git store snapshots of all files instead of just the changes?

Git saves the full state of files at each commit (see execution_table steps 3 and 6). This makes it faster and simpler to restore any commit without calculating changes.

What happens to the files when you checkout an older commit?

The working directory files are replaced by the snapshot from that commit (see execution_table step 7). This is why files look like they reverted to an earlier state.

Is the commit chain lost when you checkout an older commit?

No, the commit chain remains intact (see variable_tracker Commit Chain after step 7). HEAD just points to an older commit temporarily (detached HEAD).

Visual Quiz - 3 Questions

Look at the execution table at step 3. What does Git do at this step?

A Modifies files in the working directory

B Checks out the previous commit

C Creates the first commit snapshot of all files

D Deletes all files

💡 Hint

Check the 'Commit Created' and 'Files State' columns at step 3

At which step does the working directory files get restored to an earlier snapshot?

A Step 7

B Step 6

C Step 4

D Step 2

💡 Hint

Look for 'Files restored to Commit 1 state' in the 'Files State' column

If you modify files but do not commit, what happens to the commit chain?

A It adds a new commit automatically

B It stays the same

C It deletes the last commit

D It resets to the first commit

💡 Hint

See variable_tracker 'Commit Chain' after step 4 where files are modified but no commit is made

Concept Snapshot

Git saves full snapshots of your files at each commit.
Each commit stores the entire project state, not just changes.
You can restore any commit by checking it out.
HEAD points to the current commit.
Modifying files doesn't change commits until you commit.
This model makes history simple and fast to navigate.

Full Transcript

Git works by saving snapshots of your entire project files at each commit, not just the differences. When you add and commit, Git takes a picture of all your files as they are. This snapshot is stored as a commit and linked in a chain with previous commits. When you checkout a commit, Git replaces your working files with the snapshot from that commit, letting you go back in time. Modifying files alone does not affect commits until you stage and commit again. This snapshot model helps Git be fast and reliable in managing your project history.