<p>Git 2.23+ 中 git checkout 不再默认恢复文件，需用 git restore 或 git checkout -- 文件名；restore 默认只处理已跟踪文件，不删新增文件；恢复源取决于暂存区状态，可加 --source=HEAD 强制从 HEAD 恢复。</p>
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 版本差异导致命令语义突变，以及暂存区状态对恢复源的静默影响——这两点不确认清楚，光背命令没用。
