Git 图形客户端交互式暂存的文件块选择

同一个文件里同时有“功能修改”和“格式调整”时，整文件点一次加号会把两件事一起放进下一次提交。更稳妥的做法是打开 Git 图形客户端的差异视图，只选中本次要提交的文件块，再把它加入暂存区。下面以 VS Code 的 Source Control 为例，完成一次交互式暂存。

官方地址：https://code.visualstudio.com/docs/sourcecontrol/staging-commits

先分清 Changes 和 Staged Changes

Git 的工作区修改、暂存区快照和提交记录是三个不同状态。VS Code 的 Source Control 视图用 Changes 表示尚未暂存的修改，用 Staged Changes 表示下一次提交将包含的内容。不要因为文件已经出现在 Staged Changes，就以为后续编辑也会自动同步进去；暂存记录的是执行暂存那一刻的内容。

在 diff editor 中选中文件块

1. 打开入口：点击左侧活动栏的 Source Control，也可以使用 macOS 的 ⌃⇧G 或 Windows/Linux 的 Ctrl+Shift+G。在 Changes 下找到目标文件，例如 payment.go，点击文件名打开差异视图。
2. 定位选区：在 diff editor 中先看清新增和删除的边界。拖动鼠标选中本次要提交的连续行，选区尽量从一个完整逻辑块开始，不要把旁边的格式化改动一起框进去。
3. 执行暂存：点击选区旁 gutter 的 Stage，或右键选区选择 Stage Selected Ranges。也可以打开命令面板，运行 Git: Stage Selected Ranges。

选区提交后，文件不一定会从列表消失。如果同一文件还有未选中的修改，它会同时出现在两个区域，这正是部分暂存成功的表现。

用 Staged Changes 核对结果

回到 Source Control 面板，展开 Staged Changes，重新点击文件检查差异。理想结果是：目标代码块出现在已暂存差异中，格式化或其他无关片段仍在 Changes。这一步比直接点提交更重要，因为选区过宽时，Git 不会替你判断修改是否属于同一件事。

需要用命令行做一次只读复核时，可以在仓库根目录执行：

# 只查看指定文件已经进入暂存区的差异
git diff --cached -- path/to/payment.go

这里的 --cached 查看的是暂存区，不是工作区全部修改。若继续编辑 payment.go，再次保存后，新改动会重新出现在 Changes，需要重新选择并暂存。

选错文件块时怎样回退

如果发现暂存范围过宽，在 Staged Changes 中右键文件或选区，选择 Unstage Changes；也可以在 diff editor 中对已暂存代码块使用 Unstage。该操作只把内容移回未暂存状态，不会删除工作区修改。回到 Changes 后重新缩小选区，再执行一次 Stage Selected Ranges。

有一个边界要记住：暂存不是提交，也不是推送。只有点击 Commit 后，暂存快照才会写入本地 Git 历史；Push 则是把已经提交的记录上传到远端。把这三步分开检查，能避免“看见文件加粗就以为已经提交”的误判。

相关问题

为什么同一个文件会同时出现在 Changes 和 Staged Changes？

因为文件只暂存了一部分，剩余修改仍在工作区。这是交互式暂存的正常结果。

暂存后继续修改会覆盖原来的暂存块吗？

不会。原暂存块保持在暂存快照中，后续修改作为新的未暂存差异出现；提交前应再次复核两边的内容。

Stage Selected Ranges 选项找不到怎么办？

先确认当前打开的是 Git 仓库中的文件差异视图，并且选中了具体行。也可以从命令面板搜索 Git: Stage Selected Ranges。