Git 的分批提交功能，说穿了就两个核心命令：git add -p 和 git add -i。前者让你像挑选糖果一样，把文件里的修改一块块地选出来暂存；后者则像个菜单系统，让你先挑文件，再决定对每个文件做什么操作。很多人在实际开发中会遇到这样的场景：一个文件里同时混着功能修复、代码格式调整、调试日志打印——你肯定不想一股脑全提交，这时候交互式暂存就是救星。
git add -p 和 git add -i 是分批提交文件内多处修改的核心命令：前者逐块（hunk）交互选择暂存，支持 y/n/s/e/q 等操作精细控制；后者提供菜单式文件级操作，选 5: patch 可进入指定文件的 -p 流程。
想把一个文件里几处修改分批提交？直接 git add 会全塞进暂存区，必须是交互模式——核心就两个命令：git add -p 和 git add -i，前者专注“挑代码块”，后者管“挑文件+操作类型”。
git add -p：逐块选择修改（hunk）
这个命令适用于同一文件中混着多种改动——比如你一边修 bug 一边整理格式还顺手加了几个 console.log——需要拆成不同提交的场景。它不关心文件是否已跟踪，只盯着工作区和暂存区之间的差异块（hunk）。
y：暂存当前块；n：跳过；q：退出不暂存剩余块s：把当前大块拆成更小粒度（比如一个函数内部分行），再逐个选 —— 这是精细控制的关键动作e：手动编辑当前块内容，删掉不想提交的行（例如临时console.log或敏感值），保存后仅编辑后的内容进入暂存区- 遇到空行或纯空白变更，
git add -p默认会跳过；如需包含，得先用git diff -w确认是否真有实质差异
git add -i：按文件粒度操作 + 扩展功能
当你刚改了七八个文件，但只想提交其中三个的特定改动时，git add -i 就派上用场了。它先让你筛选文件，再决定对每个文件做什么——暂存全部？只暂存部分？撤销误操作？
- 菜单里选
5: patch后，会列出所有已修改文件，输入序号再回车，才进入该文件的-p流程 —— 别漏掉这第二步回车 3: revert能撤回已暂存的文件，但只对“已暂存未提交”的状态有效；如果已经commit了，得用git reset4: add untracked可批量添加新文件，但不会自动递归子目录里的未跟踪文件，要加.或显式指定路径- 选
6: diff查看暂存区和HEAD的差异，等价于git diff --cached，比git status更直观看到“到底暂存了什么”
常见错误与兼容性注意
交互式暂存不是万能的，有些边界情况容易翻车：
- 二进制文件（如图片、PDF）不支持
-p，git add -p会直接报错 “binary files differ”，只能整个文件暂存或放弃 - Windows 换行符（CRLF）在某些 Git 配置下会导致
-p显示大量虚假差异，建议全局设置core.autocrlf=input（Linux/macOS）或true（Windows） git add -i在旧版 Git（fatal: unable to read tree 类错误，优先升级 Git- 用
git add -p编辑块（e）时，编辑器退出必须成功（无语法错误、无空行残留），否则整个块会被丢弃，且不提示
说到底，真正难的不是记住那些选项字母，而是每次操作前问自己一句：我这次暂存，是为了让下一次 git commit 表达一个清晰、单一的意图。一旦开始靠 git add -p 或 git add -i 拆解修改，就得同步维护好暂存区和工作区的边界感——稍不注意，git status 就会同时显示 “staged” 和 “modified”，而你可能忘了哪部分还在工作区里躺着。
