上一章解决的是“Git 为什么存在”。

这一章开始解决另一个更实际的问题：

当你真的开始使用 Git 时，你眼前这些文件、改动、提交，到底分别处在什么位置？

很多人学 Git 卡住，不是因为命令难，而是因为脑子里没有地图。git add、git commit、git status 这些命令一条条看似都懂，可一旦连起来，就开始发懵。

根源通常只有一个：没有建立 Git 的三层工作模型。

这三层就是：

1. 工作区（working tree）
2. 暂存区（staging area / index）
3. 提交历史（commit history）

只要这三层清楚了，Git 的日常操作会一下顺很多。

---

一、先记住一个总图：Git 不是“改完就自动进历史”

很多新手第一次接触 Git 时，会下意识把它想成某种“增强版自动存档系统”：

• 我改了文件
• Git 应该已经知道了
• 所以历史应该也差不多已经有了

这正是误解的起点。

Git 的默认思路不是“你改了，我就替你全部收进去”，而是：

你先改；然后你决定哪些改动要进入下一次提交；最后你再明确把它们写进历史。

这意味着，一次正常的 Git 工作流里，至少会发生三件不同的事：

• 文件被修改
• 修改被挑选进入暂存区
• 暂存区内容被提交进历史

这三件事不是同一件事。

---

二、第一层：工作区——你手上真正正在改的文件

工作区就是你当前项目目录里那些真实存在的文件。

例如你有一个文档项目：

my-book/
├── README.md
├── chapters/
│   ├── 01-intro.md
│   └── 02-git-basics.md
└── images/
    └── cover.png

你现在打开 02-git-basics.md，增加了一段内容；又替换了一张截图；还顺手改了 README.md 的一句话。

这些改动此时都只发生在工作区里。

工作区的特点是：

• 它是你正在编辑的真实文件
• 它可以随时继续改
• 它还不等于“准备提交”
• 它更不等于“已经进入历史”

所以工作区最像什么？

它最像你的施工现场。

---

三、第二层：暂存区——你挑出来准备提交的那一批改动

暂存区是 Git 最容易让新手困惑、但又最值得尽早弄懂的地方。

你可以把它理解成：

下一次提交的候选清单。

也就是说，Git 并不会默认把工作区所有改动直接打包成提交，而是先让你决定：

• 哪些文件现在就进下一次提交
• 哪些改动先不提交
• 哪些变化还要再整理一下

最常见的动作是：

git add .

这条命令的本质不是“提交”，而是：

把当前改动加入暂存区。

如果你想更精确一点，也可以只加某些文件：

git add README.md
git add chapters/02-git-basics.md

这时，暂存区就开始像一个“待提交购物篮”。

为什么 Git 要设计暂存区？

因为真实工作里，你经常不会只改一件事。

例如你可能同时做了这些：

• 修正文案错别字
• 新增一小节正文
• 顺手删掉一张旧图
• 改了一点目录结构

这些改动未必应该全部混成一个提交。

有了暂存区，你就可以更有边界感地组织历史。

---

四、第三层：提交历史——真正写进版本记录的内容

当你执行：

git commit -m "docs: add first section on staging area"

Git 会把暂存区中的内容打成一个正式的历史节点。

这个节点就是一次提交（commit）。

一次提交至少表达三件事：

1. 改了什么
2. 什么时候改的
3. 这批改动被你视为一个完整的小阶段

这就是为什么提交不是“自动保存”，而是“结构化记录变化”。

提交历史最重要的价值是什么？

不是炫耀你提交得多勤。

而是让你以后可以：

• 回看某次改动的上下文
• 比较版本差异
• 找出哪次提交引入了问题
• 回到某个相对稳定的状态

所以提交历史是资产，不是包袱。

---

五、把三层连起来看：一次标准操作到底发生了什么

假设你正在写一章教材。

第一步：你修改文件

你在 chapters/02-git-basics.md 新增了一节“暂存区是什么”。

这时改动只在工作区里。

第二步：你检查状态

git status

这时 Git 会告诉你哪些文件改了、哪些还没暂存。

第三步：你把改动加入暂存区

git add chapters/02-git-basics.md

这时这份文件的当前状态进入暂存区。

第四步：你正式提交

git commit -m "docs: explain working tree and staging area"

这时暂存区里的内容进入提交历史。

所以整个过程不是“改了 = 提交了”，而是：

改了 → 选中 → 提交

这就是 Git 的最小骨架。

---

六、git status 为什么是最值得养成习惯的命令

如果只能推荐新手养成一个 Git 习惯，那通常就是：

git status

因为这条命令会直接告诉你三层之间现在是什么关系。

例如你可能会看到：

• 哪些文件被修改了但还没暂存
• 哪些文件已经暂存，准备进入下一次提交
• 当前分支是什么
• 工作区是否干净

这使它像一个“总仪表盘”。

新手最好的节奏

• 改完一会儿就看一次 git status
• 提交前一定看一次 git status
• 推送前也值得再看一眼

一旦这个习惯形成，很多误操作会大幅减少。

---

七、为什么新手不应该过度依赖 git add .

git add . 很方便，也确实非常常用。

但新手早期如果一切都无脑 git add .，容易出现一个问题：

你自己都不知道这次到底加进去了什么。

例如你原本只是想提交：

• 一段正文修改

结果实际上还顺手带进去了：

• 一个临时文件
• 一张不该提交的测试截图
• 一个没整理好的草稿

所以更稳的早期做法是：

git status
git add 某个具体文件
git status

等你的边界感更强之后，再更多使用 git add . 也不迟。

---

八、第一次可靠提交应该长什么样

很多人第一次提交时，喜欢把所有东西一股脑扔进去。比如：

• 初始化目录
• 加 README
• 写两章正文
• 加十张图
• 改结构
• 顺手修一堆字

然后一次性提交。

这并不是完全不能做，但从长期维护角度看，不是最好的习惯。

更理想的第一次可靠提交

第一次提交最好满足这几个特点：

1. 边界清楚：这次提交只做一类事。
2. 改动可解释：你一看提交说明就知道这是在干嘛。
3. 以后可回看：未来的你能迅速理解这一历史节点的价值。

例如：

git commit -m "docs: add initial repository structure"

然后第二次提交：

git commit -m "docs: add first draft of chapter 2"

再下一次：

git commit -m "docs: refine staging area examples"

这样历史就很清楚。

---

九、最常用的 7 个基础命令，放在这一章一起理解

1. git status

看当前状态。

2. git add <file>

把指定文件加入暂存区。

3. git add .

把当前目录改动批量加入暂存区。

4. git commit -m "..."

把暂存区内容写进提交历史。

5. git log --oneline

快速查看提交历史。

6. git diff

看工作区相对暂存区 / 历史的差异。

7. git diff --staged

看已经暂存、即将提交的差异。

这 7 个命令已经足够支撑大量文档型工作流。

---

十、文档作者最实用的一套工作节奏

如果你是写文档、教程、教材的人，推荐你把这一章学完后直接用下面这套节奏。

开工前

git pull

写作中

• 写完一个二级节
• 补完一组图片
• 修完一轮语言
• 改完一个示例块

就准备做一次小提交。

提交前

git status
git diff

正式提交

git add chapters/02-git-basics.md
git commit -m "docs: explain working tree, staging, and commit flow"

收工前

git push

这套工作流的好处在于：

• 历史很清楚
• 每次改动边界明确
• 出问题时更容易回头查

---

十一、新手最常见的 8 个错误

错误 1：以为改了文件就已经“进 Git 了”

没有。改动先只在工作区。

错误 2：以为 git add 就等于提交

不是。git add 只是进暂存区。

错误 3：从来不看 git status

这是最容易让人失去方向感的习惯。

错误 4：一次提交攒太多不相关改动

历史会很难读。

错误 5：提交信息毫无意义

例如 update、change、fix 这种太空泛的信息。

错误 6：工作区很乱时照样乱提

容易把不该提交的东西带进去。

错误 7：只会 git add .，不会挑文件

容易失控。

错误 8：不看 git diff 就提交

结果自己都不知道这次提交到底长什么样。

---

十二、本章小结

这一章最重要的任务，是让你真正建立 Git 的三层模型：

• 工作区：你正在改的真实文件
• 暂存区：你挑出来、准备进入下一次提交的改动
• 提交历史：已经正式记录进版本系统的历史节点

只要这三层站稳，下面这些命令就会不再显得神秘：

• git status
• git add
• git commit
• git diff
• git log

它们其实都只是在帮助你看清、移动和记录这三层之间的关系。

---

练习

请你自己做一遍下面这个最小练习：

1. 新建一个 Markdown 文件
2. 写三段正文
3. 执行 git status
4. 用 git add <file> 暂存它
5. 用 git diff --staged 看一眼即将提交的内容
6. 提交：

git commit -m "docs: add first practice chapter"

如果你做完这套练习，Git 对你来说就不再只是“命令表”，而是一个开始有结构感的系统。

---

下一章预告

下一章将继续往前推进：

• 仓库初始化后的日常节奏
• 如何写更干净的提交
• 如何看历史、比较差异、撤销本地改动
• 让 Git 开始真正服务你的文档和项目工作流