git add 是什么
git add 把工作区的改动写进暂存区（index），决定下一次提交拍下哪张快照。它是提交前的取材动作：只有 add 过的内容才会进提交，add 之后再改文件，新改动不会自动跟随，需要再 add 一次。正因为中间隔着暂存区，一次提交可以只收下同一文件的一部分改动。
各选项的收件范围
不同参数覆盖的范围差别很大：git add <路径> 只收指定文件或目录；-u 只更新已跟踪文件的修改与删除，不碰新文件；-A 把新增、修改、删除全部收下；-p 逐块询问是否入库。选错范围最常见的后果，是把不该提交的新文件一起带进这次提交。
基本信息
| 适用平台 | Linux / macOS / Windows（Git 2.x） |
|---|---|
| 语法 | git add [选项] [--] <路径>… |
| 作用方向 | 工作区 → 暂存区（index） |
| 常用参数 | -A 全部；-u 仅已跟踪；-p 交互；-n 演练 |
| 忽略规则 | 被 .gitignore 命中的文件不会入库，除非加 -f |
典型使用场景
- 准备提交：按文件或目录圈定这次提交的范围
- 拆分提交：同一文件里有两类改动时用 -p 只暂存其中一块
- 批量删除：删除若干文件后用 -u 一次性记录删除动作
- 新仓库首次提交：用 -A 把全部文件纳入版本控制
- 演练确认：加 -n 先看会收哪些文件，确认后再真正执行
- 脚本化提交：显式写出路径，避免收件范围随当前目录变化
常用示例
常用示例
git add app.py # 暂存单个文件
git add src/ docs/ # 暂存整个目录下的改动
git add -u # 只收已跟踪文件的修改与删除
git add -A # 新增、修改、删除全部收下
git add -p # 逐块选择要进入提交的改动
git add -n . # 演练：只列出会被暂存的文件
git add -N newfile.py # 先登记新文件，之后才能对它用 add -p
git add -f config.sample # 强制加入被忽略的文件常用参数对照
| 参数 | 收件范围 | 容易踩的点 |
|---|---|---|
| <路径> | 指定文件或目录下的改动 | 在子目录执行只覆盖该目录 |
| -u | 已跟踪文件的修改与删除 | 不包含新建文件 |
| -A | 新增、修改、删除全部 | 会把临时文件一起带走 |
| -p | 交互选择补丁块 | 只对已跟踪文件生效 |
| -n | 只演练、不动暂存区 | 纯预览，不会写任何状态 |
| -f | 强制加入被忽略的文件 | 误加后要 git rm --cached 撤销 |
add 之后再改同一文件会出现两种状态：已 add 的是暂存区里的版本，新改动留在工作区。提交前用 git status 看状态，用 git diff 与 git diff --staged 分别核对两边的差异。
在仓库子目录里执行 git add . 只覆盖当前目录范围，容易漏收上层文件；脚本中先切到仓库根再执行，路径写全更稳。
已被跟踪的文件不受 .gitignore 影响，要停止跟踪必须先 git rm --cached。反之，被忽略的文件想强制纳入用 git add -f，常用于保留配置样例与模板。
为什么要有暂存区
暂存区的价值在于把「改动」和「这次要提交的改动」分开。工作区里可以同时存在三类内容：已经写进暂存区准备提交的、还没决定要不要提交的、以及临时试验性的。没有暂存区就只能整文件提交，遇到一个文件里混着两种意图的改动时只能将就。
把密钥、令牌或本地环境文件 add 进去会很麻烦：即使随后删除，内容仍留在历史里。提交前先用 git status 通读清单，并让 .gitignore 覆盖 .env、凭据目录与本地配置。
核对暂存结果的命令
- git status --short 逐行确认收件清单与状态码
- git diff --staged 通读即将提交的实际改动
- git diff --cached --name-only 只列文件路径，便于脚本处理