005、Git三板斧（1）：git add - 将文件纳入版本管理

上周帮同事排查一个版本问题，他的本地代码明明改了一堆文件，提交时却只带上去两个。一查才发现，他直接 git commit -m "fix bug" 就完事了，根本没执行 git add。结果只有之前暂存区里的两个文件被提交，其他修改全留在工作区，线上bug自然没修复。这个场景让我意识到，很多新手对 git add 的理解还停留在"第一步"的层面，其实这里面门道不少。

git add 到底在做什么

很多人把 git add 简单理解为"准备提交的文件"，这个说法不够准确。更专业的理解是：git add 将工作区的变化（新增、修改、删除）注册到暂存区（Staging Area）。

Git 有三个核心区域：

工作区：你眼前正在编辑的代码目录
暂存区：一个中间缓存层，像购物车一样存放"准备结账"的改动
版本库：最终提交形成的版本历史

当你执行 git add file.txt 时，Git 实际上做了两件事：

对文件内容生成 SHA-1 哈希，存入对象库（.git/objects）
在暂存区记录该文件的索引信息

可以用 git status 验证这个过程：

bash 复制代码

# 修改文件后
git status        # 显示 modified: file.txt （红色）
git add file.txt
git status        # 显示 modified: file.txt （绿色）

红色表示改动还在工作区，绿色表示已进入暂存区，这就是最直观的信号。

几种常用姿势

添加单个文件

bash 复制代码

git add main.c

最基础的用法，适合精准控制提交内容。调试时我经常这样分文件添加，保持提交的原子性。

添加当前目录所有改动

bash 复制代码

git add .

注意这个点号表示当前目录，会递归添加所有子目录的改动。但小心它会把编译产物、临时文件也加进去，除非你在 .gitignore 里配置好了过滤规则。

添加所有类型变化

bash 复制代码

git add -A

比 git add . 更彻底，会添加整个仓库的所有变化（包括删除的文件）。团队协作时有人删了文件却没提交删除操作，用这个就能捕获到。

交互式添加

bash 复制代码

git add -p

这是我最推荐的高级用法。它会逐个展示代码块（hunk），询问是否加入暂存区。你可以：

y：添加这个块
n：跳过
s：拆分更小的块
e：手动编辑要添加的行

比如你改了一个文件但包含调试打印和实际修复，用这个就能只提交修复部分，保持提交记录的整洁。

那些容易踩的坑

坑1：添加了不该加的文件

bash 复制代码

# 手滑把编译产物加进去了
git add *.o

# 补救方法：从暂存区移除，但保留工作区文件
git reset HEAD *.o

记得先 git status 确认一下再 add，养成条件反射。

坑2：以为 add 等于备份

有同事问我："git add 之后代码是不是就安全了？" 不是的！暂存区内容还在本地 .git 目录，没推送到远程服务器。断电、硬盘损坏都会导致丢失。必须 git commit 才生成正式版本，git push 才完成远程备份。

坑3：二进制文件的大坑

bash 复制代码

# 添加了一个10MB的测试视频
git add test.mp4

Git 对二进制文件的版本管理效率很低，每次修改都会存储完整副本。如果非要管理二进制文件，考虑用 git-lfs 扩展，或者放到专门的文件服务器。

我的工作流建议

小步快跑：改完一个小功能就立即 add，别等攒了一堆改动。这样 commit 信息好写，回退也方便。
多用 git add -p：刚开始觉得麻烦，熟练后能极大提升提交质量。特别是修复bug时，调试代码和实际修复混在一起，用这个能精准剥离。
提交前做diff检查：
bash 复制代码
```
git add .
git diff --staged    # 查看暂存区与上次提交的差异
```
这个习惯帮我避免了很多次错误提交。
善用 .gitignore ：在项目根目录放好 .gitignore 文件，把编译目录、IDE配置、日志文件等提前排除。这样 git add . 时就不会误加垃圾文件。
理解 add 的本质 ：它不是简单的"添加文件"，而是"记录快照"。执行 git add 时，Git 保存的是文件那一刻的内容。之后你再修改文件，需要重新 add 才能更新暂存区的版本。

刚开始用 Git 时，我也觉得 git add 多此一举，为什么不直接 commit？现在明白了，这个设计恰恰体现了 Git 的灵活：暂存区让你有机会整理提交，把不相干的修改拆成多个逻辑提交，或者把多个文件的改动合并为一个完整功能提交。下次提交前，试试 git add -p 仔细看看每个改动，你会发现提交历史的质量明显提升。