Recovery
误用 git clean 后的恢复
git clean 删除未跟踪文件后，优先从 IDE 本地历史、系统快照或构建产物来源恢复，并建立 clean 前预演与备份习惯。
- 正在处理 Git 误操作的人
- 想提前建立保守恢复习惯的协作者
- 先停手，不继续乱试命令
- 能执行 `git reflog`、`git status`、`git log --graph`
- 还没保住旧位置就继续 reset / rebase
- 在没判断影响面时直接改共享历史
引用与延伸阅读
- Git clean [官方]
- Git stash [官方]
- Git Tools Stashing and Cleaning [书籍]
学完这篇你会掌握什么
- 理解 误用 git clean 后的恢复 的核心作用和适用场景
- 掌握 误用 git clean 后的恢复 的基本用法和常用参数
- git clean 删除未跟踪文件后，优先从 IDE 本地历史、系统快照或构建产物来源恢复，并建立 clean 前预演与备份习惯。
- 理解 先确认删了什么 相关的概念
- 掌握 可尝试的恢复来源 相关的操作
- 知道在什么场景下使用该命令，什么场景下避免使用
git clean 清理的是未跟踪文件，Git 对这些文件通常没有历史记录。
所以恢复重点是“外部来源”，不是 reflog。
先想一个问题
你刚刚在 Git 里做了一个操作，结果发现不是你想要的效果——甚至可能弄丢了提交。这种情况不是第一次了，你想建立一套可靠的方法来应对各种误操作场景。
先确认删了什么
如果你先执行过 -n 预演，会更容易定位清单：
git clean -nd
若已经删除，马上停止进一步写盘操作，减少覆盖风险。
垃圾筒编辑器撤销文件系统恢复
未跟踪文件编辑器缓存系统备份
reflog 对 clean 帮助不大，因为 clean 不触发引用变化。
可尝试的恢复来源
- IDE Local History / Time Machine / 文件系统快照
- 构建产物或生成脚本可重建内容
- 同事分支或远端附件里可能有副本
为什么 reflog 常帮不上忙
reflog 记录的是引用移动，不记录未跟踪文件内容。
这类事故预防通常比恢复更关键。
预防策略（强烈推荐）
清理前先做两步：
git clean -nd
git stash push -u -m "pre-clean backup"
第一步看范围，第二步给未跟踪文件留保险。
-x 会连忽略文件一起删，风险很高。除非你明确知道当前目录中哪些文件可重建，否则先预演再决定。
接下来建议继续看什么
给你的练习
- 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
- 尝试该命令的不同参数选项，对比输出结果的差异
- 模拟一个需要使用该命令的实际场景，完整走一遍操作流程
延伸阅读
沿着同一主题继续深入：