- 已经会基本提交和分支操作的开发者
- 想理解命令边界与风险的人
Command Reference
git add 教程
说明 git add 如何把工作区改动加入暂存区、如何用 patch 精细暂存，以及怎样避免把不相关改动混进同一次提交。
- 知道工作区、暂存区、提交的基本关系
- 能读懂 `git status` 和简单历史图
- 误把本地整理命令用到共享历史
- 在没确认恢复路径前直接继续改写历史
一句话理解
git add 会把工作区里选中的内容复制进暂存区，让下一次提交只使用这份暂存快照。
git add 不是“保存文件”，而是更新 index。也正因为如此，同一个文件可以同时存在“已暂存的部分”和“还没暂存的部分”。
它真正解决的是什么问题
Git 不是“改完文件直接提交”。
它要求你先回答一个问题：
这次提交到底要讲哪一个完整而清晰的故事？
git add 就是为这个问题服务的。
它让你可以：
- 把一次混乱的开发过程拆成几个逻辑提交
- 只暂存已经准备好评审的代码
- 暂时把试验性改动留在工作区里
- 在冲突解决后，只把真正解决完的文件标记进下一步
最常用的几种写法
git add README.md
git add src/
git add .
git add --patch
git add README.md：暂存单个文件git add src/：暂存某个目录git add .：暂存当前目录下发现的所有改动git add --patch：按 hunk 交互式选择要不要暂存
一套更稳的日常流程
实际协作里，更推荐这样做：
- 先用
git status看当前状态 - 再用
git diff看工作区里到底改了什么 - 用
git add <path>或git add --patch精确暂存 - 用
git diff --staged检查这次提交真正会包含什么 - 确认无误后再 commit
例如：
git status
git diff
git add --patch
git diff --staged
git commit -m "fix: keep search fallback stable"
如果一次提交应该只表达一个意图，那么 index 就是你在进入历史之前做最后筛选的地方。
最常见的误区
很多问题并不是命令不会用，而是暂存太随意。
典型错误包括：
- 用
git add .把调试代码、格式化和真正修复一起带进去 - 以为一个文件“已经 add 过”就代表后续新增的改动也会自动进入提交
- 解决完冲突后忘记重新
add标记已解决状态 - 明明需要拆小提交，却仍然整文件整目录地暂存
为什么 --patch 很重要
git add --patch
它之所以关键，是因为它让你可以把这些东西拆开：
- 真正的 bug fix 和顺手做的重构
- 生产代码改动和临时日志
- 已经确定的修改和还在犹豫的实验
这往往决定了你的提交会是：
- 易于 review、易于 cherry-pick、易于 revert 的清晰提交
- 还是“改了很多但说不清到底改了什么”的混乱提交
如何理解“同一个文件同时有已暂存和未暂存内容”
设想你对一个文件做了两轮修改：
- 第一轮是真正的逻辑修复
- 第二轮是临时加的调试输出
- 然后你用
git add --patch只暂存第一轮
这时 Git 的状态就是：
- 暂存区里只有逻辑修复
- 工作区里还保留着调试输出
这不是 Git 在“搞复杂”，而是它给了你比“整文件提交”更高的表达能力。
图例理解
工作区改动暂存区快照当前分支
更新后的 index更干净的 staged diff更安全的下一次提交
如果不知道这次 add 到底带进来了什么，先看 `git diff --staged` 再继续。
边界与判断
git add通常不会移动分支指针，但它会直接改变“下一次提交意味着什么”。git add .很快，但不够谨慎。只要改动混杂，就更适合按路径或按 patch 暂存。- 在切分支、做恢复、准备 rebase 之前，清楚区分 staged 和 unstaged 非常重要。
暂存区只是本地状态的一部分，不是独立备份点。如果你需要可靠恢复点，应该 commit 或 stash，而不是以为“已经 add 过了就安全”。
跟着做一遍
目标不是背命令，而是感受到工作区和暂存区的差别。
git switch -c lab/add-demo # 在一个文件里同时写入真正修复和临时调试输出动手试
- 先运行 `git diff` 看全部改动。
- 运行 `git add --patch`，只暂存真正修复的部分。
- 运行 `git diff --staged`，确认 staged 内容已经干净。
- 保留调试输出在工作区里，单独完成这次提交。
- 提交里只会包含你暂存的那部分改动。
- 工作区仍然可以保留没准备好的修改。
- 你会得到更干净、更容易 review 的历史。
- 如果 `git diff` 没输出，检查改动是不是已经进了 staged。
- 如果提交里还是混入了不相关内容，通常是暂存范围太宽。
- 如果刚解决完冲突，记得真正结束冲突流程前要重新 `git add`。