git 2.23+ 中 git checkout 不再默认恢复文件，需用 git restore 或 git checkout -- 文件名；restore 默认只处理已跟踪文件，不删新增文件；恢复源取决于暂存区状态，可加 --source=head 强制从 head 恢复。

git checkout 恢复单个文件时，为什么没反应？

因为 git checkout 在 Git 2.23+ 默认不支持直接恢复工作区文件了——它被拆成了 git restore。如果你用的是较新版本 Git（比如 macOS Homebrew 安装的、或 Windows Git for Windows 2.30+），敲 git checkout README.md 实际上会尝试切换分支，而不是恢复文件。

• 确认 Git 版本：git --version，2.23 及以上建议改用 git restore
• 想快速恢复一个文件：用 git restore README.md
• 如果坚持用 git checkout，必须加 -- 分隔符：git checkout -- README.md（否则 Git 以为你要切分支）
• -- 不是可选的“风格”，是命令解析必需的，漏掉就可能误操作分支

git restore 怎么只恢复修改、不删新增文件？

git restore 默认只影响已跟踪（tracked）文件，对 git status 里显示为 untracked 的新文件完全无感——这是安全设计，不是 bug。

• 恢复所有已修改的 tracked 文件：git restore .（注意结尾的点）
• 但这个命令不会删你新建的 temp.js 或 notes.txt，它们仍保留在工作区
• 如果误删了新文件，Git 帮不上忙，得靠系统回收站或备份
• 想连 untracked 文件一起清空？那是 git clean -fd 的事，和 restore 无关，且不可逆

撤销修改时，index（暂存区）状态怎么影响结果？

关键看文件是否执行过 git add：没 add 过，git restore 从 HEAD 恢复；已 add 过，它默认从暂存区恢复——这会导致“越恢复越不对”的错觉。

Lovefromio Github

使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。

下载

• 比如改了 config.json → git add config.json → 再改一次 → git restore config.json：恢复的是你 add 那一刻的内容，不是原始 HEAD
• 强制从 HEAD 恢复（忽略暂存区）：git restore --source=HEAD config.json
• 想一步清空暂存区 + 工作区？git restore --staged --worktree config.json

Windows 下中文路径文件恢复失败，怎么办？

Git 默认对 Windows 路径编码处理较弱，尤其含中文、空格、括号时，git restore 或 git checkout -- 容易报 pathspec 'xxx' did not match any files。

• 先用 git status --porcelain 看 Git 认出的真实路径名（它会转义空格为 \ ，中文通常正常）
• 复制输出里的完整路径，粘贴进 restore 命令，别手动输中文
• 或者 cd 进对应目录，用相对路径：git restore "我的配置.json"（加英文双引号包裹）
• 长期建议在 Git 配置里启用路径大小写敏感关闭：git config core.ignorecase true（Windows 默认已开，但某些 WSL 场景需显式设）

事情说清了就结束。最常卡住的地方其实是 Git 版本差异导致命令语义突变，以及暂存区状态对恢复源的静默影响——这两点不确认清楚，光背命令没用。