Git partial staging 怎么只提交一个文件中的部分修改

如果一个文件同时包含“修复逻辑”和“顺手改文档”两类变更，不必整文件一起提交。用 git add -p -- path/to/file 进入交互式补丁选择，只回答每个 hunk 是否加入暂存区；提交时 Git 只会带走已暂存的那一部分。

官方地址：https://git-scm.com/docs/git-add

先记住三点：先用 git diff 看工作区；再用 git add -p 选补丁块；最后用 git diff --cached 和 git diff 分别检查已暂存、未暂存内容。

先把同一个文件的修改分成可选择的补丁块

Git 的暂存区（index，也叫 staging area）保存下一次提交准备带走的内容。git add -p 不会直接把整个文件加入暂存区，而是把工作区与暂存区之间的差异拆成一个个 patch hunk，让你逐块决定。

1. 进入文件所在仓库。在项目根目录执行下面的命令，先确认改动范围。

# 只查看这个文件相对当前暂存区的未暂存修改
git diff -- path/to/file

如果输出里已经混有多个相互独立的区域，就适合做 partial staging。图 1 的原创界面示意把同一个文件的两个补丁块分开显示，读者可以先判断哪一块属于当前提交。

用 git add -p 逐块选择要提交的内容

1. 启动补丁选择。把路径写在 -- 后面，避免文件名被当成选项。

# 只对一个文件进入交互式补丁选择
git add -p -- path/to/file

Git 显示一个 hunk 后，会等待你的选择。常用按键如下：

最稳妥的顺序通常是：能分开的先按 s 拆开，再对目标块按 y，其他块按 n。如果当前 hunk 把相邻的两类修改粘在一起，先不要贸然按 y，否则它们会一起进入暂存区。

暂存后怎么确认提交内容没有混入其他修改

1. 查看准备提交的内容。下面的命令只看暂存区相对 HEAD 的差异。

# 检查已经进入下一次提交的部分
git diff --cached -- path/to/file

# 检查仍留在工作区、尚未暂存的部分
git diff -- path/to/file

验收时要同时看两份结果：第一份只能出现本次要交付的修改；第二份可以保留下一次再提交的修改。如果发现暂存区选多了，可以用 git restore --staged -- path/to/file 取消整个文件的暂存，再重新运行 git add -p；这不会删除工作区内容。

确认无误后再提交

1. 提交已暂存部分。确认 git diff --cached 只包含目标修改后，再执行提交。

# 只提交暂存区，不会把仍在工作区的修改一起带走
git commit -m "fix: adjust validation rule"

提交完成后，工作区里被 n 跳过的修改仍然存在。下一次提交前再次执行 git diff，然后继续用 git add -p 选择即可。

常见问题：

• 为什么看不到想选的行？默认按 hunk 展示，先按 s 尝试拆分；如果两处修改没有足够上下文间隔，Git 可能仍把它们视为同一块。
• 按了 y 后能反悔吗？可以退出后用 git restore --staged -- path/to/file 清掉该文件暂存内容，再重新选择；它不会回滚工作区文件。

把“选择补丁”和“验收暂存区”分成两个动作，partial staging 就不再是凭感觉按键，而是一次可复核的提交准备流程。