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.

Start with why learn Git in the AI era, then open the interactive reading. The complete path keeps the articles, interactives, and temporary-repository labs for all ten topics in one sequence. The knowledge map explains when this conceptual route should lead to a change or collaboration decision.

Flagship series

1. Snapshots and State: HEAD, Index, and Working Tree · Interactive · Lab
2. The Object Graph: Blobs, Trees, and Commits · Interactive · Lab
3. The Index Is the Next Commit Draft · Interactive · Lab
4. References, HEAD, and Identity · Interactive · Lab
5. Reachability, Reflog, and Recovery · Interactive · Lab
6. Merge Starts with a Common Ancestor · Interactive · Lab
7. Rebase Replays Changes onto New History · Interactive · Lab
8. A Remote Is Another Repository; origin/main Is a Local Record · Interactive · Lab
9. Worktrees Share Objects and Isolate Checkout State · Interactive · Lab
10. Logical Snapshots and Physical Storage Are Separate Layers · Interactive · Lab

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

This is an operational overview. It does not mean a file can belong to only one area or that every operation moves it away. The working tree, index, and HEAD can represent different versions simultaneously. A remote is another repository with its own objects and references.

Compare versions and references before deciding what an operation will change. A branch points to a commit; a commit refers to a snapshot. A branch is not another directory.

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:

• Preserve working edits before recovery; restoring working files may discard edits and is not a generic save operation.
• To unstage only, git restore --staged updates the index while preserving the working tree.
• Before rewriting commits, establish references, sharing, and recovery options. Different reset modes have different effects on working files.
• For shared history, usually append a revert commit. Database and external effects need separate treatment.

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.