my-git

Git Mental Model

English

中文

This page is the entry point to the Git Mental Model series. The four-area model is useful for quick operational decisions. The deeper series explains why Git behaves this way through snapshots, objects, refs, and history transformations.

Flagship series

1. Snapshots and State: HEAD, Index, and Working Tree
2. The Object Graph: Blobs, Trees, and Commits
3. The Index Is the Next Commit Draft

The first chapter uses three versions of one file to show what git add and git commit actually record. It includes an interactive demo and a runnable lab.

The second chapter follows a commit into the object database, separates the responsibilities of blobs, trees, and commits, and includes an object-graph interactive and a runnable lab.

The third chapter goes deeper into the index through partial staging, git diff --cached, safe unstaging, and conflict stages 1, 2, and 3. It includes an index-draft interactive and a runnable lab.

Four-area quick model

To understand Git, first understand the four areas:

working tree -> index -> local repository -> remote repository

Working tree

The files you are currently editing.

Check:

git status

Index

Also known as the staging area, it represents what the next commit will contain.

git add <file>
git diff --cached

Local repository

The local commit history.

git log --oneline

Remote repository

The remote repository, such as origin on GitHub.

git fetch
git pull --rebase
git push

Key idea

Most Git commands are about moving content between these areas.

Determine which area the file is in first before choosing a command, and errors will be significantly reduced.

Common Command Relationships

Command	Primary Impact
git add	Working tree -> Index
git commit	Index -> Local repository
git restore	Discard or restore working tree content
git restore --staged	Restore the index from HEAD by default; keep the working tree unchanged
git push	Local repository -> Remote repository
git fetch	Remote repository -> Local remote reference
git pull	fetch + merge or fetch + rebase

Why This Model is Important

Many Git accidents stem from not clearly determining which area the current change is in.

For example:

• If the change is in the working tree, use git restore or git stash.
• If the change is already staged, use git restore --staged first.
• If the commit has been generated but not pushed, you can use reset or commit --amend.
• If the commit has been pushed, usually prioritize using revert.

Judging the area first and then choosing the command is the primary principle of Git troubleshooting.

Extended Reading

• Pro Git: Git Basics
• git status Official Documentation
• git restore Official Documentation
• Recommended Reading Index

This site is open source. Improve this page.