Git 的三个区域：理解一次提交到底保存了什么

刚接触 Git 时，很容易把 git add 理解为「把文件加入仓库」。更有用的理解是：它把文件此刻的内容写入暂存区，准备成为下一次提交的一部分。

三个区域，各有一份状态

工作区  ── git add ──→  暂存区  ── git commit ──→  本地仓库
正在编辑的文件          下一次提交的快照             已记录的历史

工作区是你眼前的文件；暂存区是下一次提交的候选状态；本地仓库保存已经提交的对象与历史。对于普通的 git commit，提交内容来自暂存区。

一个常见的小意外

先修改 notes.md，执行 git add notes.md，然后继续编辑该文件。此时工作区与暂存区保存的是不同状态。

git status
git diff
git diff --staged

git diff 通常用来观察工作区相对于暂存区的未暂存改动；git diff --staged 用来观察暂存区相对于 HEAD 的待提交改动。两份差异可以同时存在。

如果直接提交，第二次编辑的内容通常不会自动进入这次提交。你需要再次暂存想要包含的改动。

把提交当成一个完整想法

一次提交最好可以用一句话解释：修复某个问题、增加一项能力，或者调整一个清晰的结构。用暂存区组织提交，有助于把同一工作区中的不同意图分开。

# 按修改块选择要暂存的内容
git add -p

# 提交前审阅真正将要记录的变化
git diff --staged

git commit -m "docs: explain DNS lookup flow"

暂存区不是多余的一步，而是一次编辑与一次提交之间的审阅边界。

提交不等于推送

git commit 在本地记录历史，git push 才尝试把相关对象与引用更新发送到远程仓库。离线也可以提交；推送失败并不意味着本地提交消失。

同样，.gitignore 主要影响未跟踪文件的默认处理方式。把已经跟踪的文件写进忽略规则，不会自动停止跟踪它，更不会删除已经进入历史的敏感内容。

形成一个可靠习惯

先看 status 确认范围，再看 diff 理解内容；暂存后，再用 diff --staged 审阅一次。提交之前读一遍真正要保存的差异，往往能省下之后排错的时间。

继续阅读

• Pro Git：记录每次更新到仓库
• Git：git-diff