GitHub Desktop 如何撤销部分文件的提交

在 GitHub Desktop 里，“撤销部分文件的提交”要先看提交是否已经推送。最近一次提交还没有 Push origin 时，可以点击 Undo 把提交拆回工作区，再按文件勾选后重新提交；如果提交已经推送，Revert Changes in Commit 的粒度是整次提交，不能直接在菜单里挑几个文件。此时应保留共享历史，用一个后续提交只修正需要撤回的文件。

官方地址：https://desktop.github.com/

先判断提交状态，再选择撤销路径

打开仓库后先看左侧 History，定位误提交的记录，再确认当前分支是否已经同步远端。判断可以按下面的表来做：

未推送提交：Undo 后只重新提交需要的文件

这是最适合“部分文件撤销”的路径。假设一次提交同时包含 src/app.go、config.yaml 和 README.md，但你只想把前两个放进整理后的提交。

1. 在左侧切换到 Changes，确认当前显示的是误提交后的本地状态。
2. 在提交信息区域点击 Undo。GitHub Desktop 会把最近提交恢复到工作区，分支回到上一个提交。
3. 回到文件清单，只勾选要保留在本次提交中的文件；取消勾选的文件不会被删除，只是留在未提交改动里。
4. 在 Summary 填写新的提交说明，点击 Commit to feature（按钮名称会随分支变化）。

提交后先不要急着 Push。看左侧是否还留着未选文件，再点击新提交检查差异，确认它只包含选中的文件。这样既能拆分提交，也能避免把“不想撤销但暂时没整理好”的改动一起丢掉。

已推送提交：用后续提交完成部分回滚

已推送的提交通常已经被其他人拉取，直接 reset 或强推会改变共享历史。GitHub Desktop 的官方操作是对整条提交执行 Revert Changes in Commit，它会留下原提交并新增一次反向提交；如果只想撤回其中几个文件，就不要把这个命令当成部分选择功能。

1. 在编辑器中只修改需要撤回的文件，把它们恢复到目标版本；不要顺手覆盖同一提交里的其他文件。
2. 回到 Changes，逐个查看差异，确认红绿行的方向确实是“撤回”，而不是把当前工作修改也抹掉。
3. 填写类似“撤回配置文件误提交”的 Summary，点击 Commit to feature。
4. 确认变更范围后点击 Push origin，让远端通过新提交得到最终状态。

如果整个提交都应撤回，才在 History 中右键选择 Revert Changes in Commit。多个提交需要回滚时，优先从新到旧处理，能减少冲突机会。

提交后的验收与常见问题

验收至少做四项：History 中有清楚的新提交；Changes 中没有意外遗留或丢失的文件；差异只覆盖目标文件；Push origin 后分支状态显示已同步。需要保留暂时不提交的文件时，可以先用 Stash 保存，避免它们混入下一次操作。

点击 Undo 会删除文件内容吗？

Undo 的目标是撤销本地提交并把改动放回工作区，不等于丢弃改动。真正会删除本地未提交内容的是 Discard Changes，点击前要认真核对确认窗口。

已推送提交能不能只在 History 里选一个文件撤销？

不能把 Revert Changes in Commit 当作文件级选择器。部分撤回应形成新的修正提交，并在 Changes 中用差异确认目标文件。

为什么重新提交后还有文件显示在 Changes？

这通常是取消勾选的文件仍被保留为未提交改动，属于预期结果。确认它们内容正确后，再决定下一次提交或 Stash。