git add -p 是 git 原生命令，按逻辑变动块（hunk）交互式选择暂存部分修改，支持 y/n/s/e 等操作，适用于精准提交补丁、保留调试代码等场景，不改变工作区，错误可用 git reset -p 撤回。
git add -p 是唯一能真正按逻辑块（hunk）选择性暂存的原生命令，不需要插件、不依赖 GUI，改了 20 行代码但只想提交其中 3 行？就靠它。
什么时候必须用 git add -p 而不是 git add
直接 git add 文件名 会把整个文件所有修改一股脑塞进暂存区，根本没法“挑着提交”。常见踩坑场景包括：
- 修复线上 bug 时只改了一处，但顺手加了
console.log或调试注释 ——git add -p可跳过这些行 - 重构一个函数，改了逻辑又调了格式，想拆成两个提交：一个纯功能变更，一个纯格式整理
- 同一文件里混着安全补丁、日志增强、变量重命名，需要分 commit 方便 CR 和回滚
-
git status显示文件已修改，但你不确定哪些改动该进本次提交 ——git add -p强制你逐块确认
git add -p 的交互选项怎么选才不中断流程
运行后你会看到类似提示：Stage this hunk [y,n,q,a,d,s,e,?]。实际高频操作只有四个，其他基本不用：
-
y：确认暂存当前块（最常用） -
n：跳过，留在工作区（比如调试语句、临时 TODO） -
s：把当前块再切细（例如一个 15 行的 if 块，s可能拆成 condition 判断 + body 执行两部分） -
e：手动编辑块内容（慎用！删掉不想提交的行即可，别动行首+/-或缩进，否则报error: patch failed） - 误按
q会退出，未处理的改动全保留在工作区，不会丢
git add -i 是什么？和 git add -p 怎么配合
git add -i 是文件粒度的菜单式入口，适合先筛文件、再选操作。它本身不直接处理代码块，但菜单里选 5: patch 就能跳转到指定文件的 git add -p 流程。
- 刚改了 8 个文件，但只想对其中
src/utils.js和tests/api.test.js做部分暂存？先git add -i→ 选5→ 输入对应序号 → 回车（别漏这步！） -
3: revert可撤回已暂存但还没 commit 的文件，但仅限“已暂存未提交”状态；如果已经git commit了，得用git reset -
4: add untracked批量加新文件，但不会递归子目录，要加.或显式写路径 -
6: diff等价于git diff --cached，比git status更清楚看到“到底暂存了什么”
Windows 下容易卡住或乱码？几个硬核避坑点
Git Bash 默认支持 git add -p，但 Windows Terminal 或 CMD 中可能出问题：
- 终端编码不是 UTF-8 时，中文路径或符号显示异常 → 在终端设置里强制启用 UTF-8
- 遇到空行或纯空白变更（比如只改了缩进），
git add -p默认跳过 → 先运行git diff -w确认是否真有实质差异 - 编辑块时（
e操作）保存前务必检查：每行开头的+（新增）或-（删除）不能删，缩进层级不能错，否则 Git 解析失败 - 操作错了？用
git reset -p可反向撤回暂存的块，和git add -p操作逻辑对称
y。一旦习惯，git add -p 就成了写干净 commit 的第一道过滤网。
