最可靠方法是git log --all --diff-filter=d --summary，它强制过滤删除操作、覆盖所有分支，并通过“delete mode”确认真实删除，避免遗漏跨分支或重命名场景。
能直接定位，但必须用对参数组合，否则容易漏掉跨分支删除或重命名场景。
git log --diff-filter=D 查找删除提交
这是最常用也最可靠的起点。仅靠 git log -- file.txt 会显示该文件所有变更（包括修改、重命名），但不会突出“删除”动作；而加 --diff-filter=D 后，Git 只返回真正执行了删除操作的提交。
-
--diff-filter=D是硬性过滤，不是“包含删除字样”，而是检查 Git 内部 diff 操作类型为 delete - 务必加上
--all，否则只查当前分支，如果文件是在 feature 分支上删的、后来合并进 main，不加--all就看不到 - 如果路径含空格或特殊字符，记得用引号包裹：
git log --all --diff-filter=D -- "config/production.yml" - 加
--oneline --summary能快速确认是否真删了：delete mode 100644这行才是关键证据，别只看提交信息里有没有“remove”字眼
git log -S 搜索被删代码片段
当文件名记不清、或者想定位某段逻辑（比如函数定义、SQL 查询）在哪次提交中消失时，-S 比路径更有效。它扫描的是“引入或删除该字符串”的提交，不依赖文件路径是否存在。
GitHub Hosts CN
下载
GitHub Hosts 更新工具（仅限中国用户），安全更新系统hosts文件，保留原有非GitHub条目，仅替换GitHub相关地址。支持备份恢复和风险提示。用于解决GitHub访问问题。
-
git log -S"function cleanupCache()"会列出所有让这行代码首次出现或彻底消失的提交 - 注意：-S 对大小写敏感，且匹配整行字符串（不含上下文），所以不要写太短的词，比如
-S"err"会炸出几百条 - 如果代码被重命名后保留，-S 不会触发；但如果整段被删，它大概率比路径搜索更快命中目标提交
- 配合
--since="2 weeks ago"可缩小范围：git log -S"API_TIMEOUT_MS" --since="3 days ago"
git log --follow 处理重命名后删除
有些文件不是直接删的，而是先重命名（如 config.yml → config.prod.yml），再删新名字。这时单纯查原路径会断档，--follow 能把重命名链串起来。
-
git log --follow --oneline -- config.yml会显示从创建到最终删除的完整生命周期，即使中间改过名 - --follow 必须单独作用于一个文件路径，不能和
--all或--diff-filter混用（Git 报错） - 如果
--follow没返回删除记录，说明最后一次 rename 后没删，或者删的是 rename 后的新路径 —— 此时得换用新路径再试一次 - 它不支持通配符，也不能用于已彻底从工作区消失的路径（必须至少还存在一次历史 commit 中）
删完才发现？用 reflog 找 HEAD 移动痕迹
如果文件已经删了、连 git log -- file.txt 都不返回任何结果（即 Git 认为该路径从未存在过），说明它可能在很早的提交里就被删了，或者你本地执行过 git reset --hard 导致 HEAD 跳跃，历史断层。
- 运行
git reflog或git log -g，翻看最近 HEAD 的移动记录，找带checkout、reset、commit的行，时间戳比你发现文件不见的时间早几秒的那条，往往就是删除发生的位置 - reflog 条目里的 hash（如
HEAD@{3}）可直接当 commit ID 用：git show HEAD@{3} --stat看当时删了哪些文件 - reflog 默认只存 90 天，且
git gc可能提前清理，所以别等太久才查 - 它查不到远程分支的删除操作，纯属本地操作日志，别指望靠它找回别人在 origin 上删的文件
真正难的不是命令本身，而是判断“删除”到底指哪一层：是工作区删了没 commit？是 commit 里删了但还没 push？还是别人在远程删完又 force push 覆盖了历史？每种情况对应不同的恢复路径，别一上来就 git checkout。
