git add -p 是 Git 原生命令，按逻辑变动块（hunk）交互式选择暂存部分修改，支持 y/n/s/e 等操作，适用于精准提交补丁、保留调试代码等场景，不改变工作区，错误可用 git reset -p 撤回。
能只提交部分修改，而且是 Git 原生命令，不用装插件、不依赖 GUI —— 关键就是 git add -p。
什么是 git add -p？它到底在干啥
它把当前工作区的每个「变动块」（hunk）单独拎出来，让你逐个决定：这个改动要不要加到暂存区。不是按文件，是按逻辑块，比如一个函数里改了两行、删了一行，它会拆成多个可选单元。
常见错误现象：git status 显示文件已修改，但你只想提交其中 3 行，其余留着调试 —— 直接 git add 文件名 会全塞进去，git add -p 才是解法。
- 适用场景：修复线上 bug 时只提交补丁部分；重构中保留实验性代码不提交；CR 前清理掉调试
console.log但保留功能改动 - 它不改变工作区，只影响暂存区，操作错了随时
git reset -p撤回 - Windows 上默认终端可能显示乱码或卡住，建议用 Git Bash 或 Windows Terminal + UTF-8 编码
git add -p 的交互选项怎么选才不翻车
运行后你会看到类似这样的提示：Stage this hunk [y,n,q,a,d,s,e,?]? —— 别慌，90% 场景只用前四个：
-
y：确认暂存这个块（最常用） -
n：跳过，这个块不进暂存区（留着继续改） -
s：把当前块再切细（比如一整个 if 块，s可能拆成 condition 部分和 body 部分） -
e：手动编辑这个块（小心！改完保存退出，格式必须合法，否则命令中断） - 误按
q会直接退出，没暂存的改动还在工作区，不会丢
容易踩的坑：e 编辑时删掉行首的 + / - 或改错缩进，Git 会报错 error: patch failed，此时只能关掉编辑器重来。
遇到合并冲突或二进制文件时 git add -p 失效怎么办
它只处理文本文件的 diff，对图片、PDF、node_modules 里的文件完全没反应 —— 这不是 bug，是设计如此。
更隐蔽的问题：文件编码不是 UTF-8（比如 GBK），或者换行符混用（CRLF/LF），git add -p 可能直接跳过该文件，也不报错，容易误以为“没改动”。验证方法：git diff --no-color 文件名 看是否输出正常 diff。
- 解决办法：先统一换行符（
git config --global core.autocrlf trueon Windows），或用iconv转编码 - 想对非文本文件做选择性提交？不行。只能靠
git add -i（交互式）选文件粒度，或手动复制改动到新文件再提交 - 如果
git add -p提示No changes.但git diff有输出，大概率是 core.whitespace 或 autocrlf 导致 Git 认为“无实质变更”
替代方案：什么时候不该硬刚 git add -p
当改动分散在几十个文件、每文件就改 1–2 行，git add -p 会反复问几十次，效率反而低。
- 更快的做法：
git add -i→ 选5（patch）→ 再选具体文件，缩小范围后再-p - IDE 用户：VS Code 的“暂存所选行”右键菜单、WebStorm 的 partial commit 功能，底层调的也是
add -p，但省去记忆命令 - 脚本化需求（比如 CI 中自动挑出 test 目录下的改动）：用
git diff --name-only --diff-filter=M | xargs git add配合路径过滤，-p不适合自动化
真正难的不是命令本身，而是判断哪些块该合起来提交 —— 比如一个 bug 修复涉及 UI 层和 API 层，强行拆成两个 add -p 块，会导致暂存区语义断裂。这时候宁可多花半分钟想清楚边界，别让 -p 变成“机械分块”。
