Git 需要一个回收站
内容提要
文章主张 Git 应提供类似回收站的可恢复丢弃功能。目前 Git 只能恢复已提交或暂存的内容，未跟踪文件删除后无法找回，而编辑器混淆不同状态，误点丢弃可能导致工作永久丢失。作者建议丢弃前保存文件内容与路径，支持选择性恢复，并设置容量与保留规则。
延伸解读
编辑器统一视图下的状态混淆风险
文章指出，编辑器将已提交、已暂存、未暂存和未跟踪文件统一显示为“更改”，但它们的可恢复性截然不同。点击“丢弃”对已跟踪文件可能只是从索引或提交恢复，对未跟踪文件则是从磁盘永久删除。这种界面上的统一掩盖了后果的差异，容易导致误操作。读者应意识到，在Source Control面板中执行丢弃前，需明确当前文件的实际Git状态。
现有恢复手段的边界与局限
文章强调，git restore只能从索引或提交重建内容，无法恢复Git从未记录过的字节；git clean会删除未跟踪文件，-n仅预览。VS Code文档说明，丢弃已跟踪文件会恢复暂存或提交版本，丢弃未跟踪文件则删除，且将未跟踪文件移至回收站需特定设置且不保证。系统回收站对已跟踪文件的丢弃编辑通常无效，因为文件是被旧内容替换而非删除。
实现Git回收站的关键设计考量
文章提出，有用的git trash应在修改工作树前捕获被移除文件的精确状态（内容、路径、跟踪状态），并持久化恢复条目，保存失败则删除失败。恢复需支持选择性，避免恢复所有更改；若原路径被占用，应报告冲突并提供替代位置。还需处理大文件、敏感信息、远程环境无回收站等边界，设置大小限制和保留规则，且不得在永久删除时显示“已移至回收站”。
Q&A
为什么说 Git 需要一个回收站？
因为 Git 只能恢复已提交或暂存的内容，未跟踪文件删除后无法找回，而编辑器混淆不同状态，误点丢弃可能导致工作永久丢失。
Git 中哪些内容可以恢复，哪些不能？
已提交内容在仓库历史中，通常可恢复；已暂存内容在索引中，可能可恢复；未暂存内容在工作树中，Git 不一定保存了当前字节；未跟踪内容只是磁盘文件，Git 没有副本，删除后无法恢复。
git restore 和 git clean 有什么区别？
git restore 可以从索引或提交重建内容，但无法重建 Git 从未记录的字节；git clean 则从工作树中删除未跟踪文件，其 -n 选项仅预览删除。
一个理想的 git trash 操作需要保存哪些信息？
需要保存文件内容、路径，以及每个文件是已跟踪、已暂存、未跟踪还是被忽略的状态，并记录持久的恢复条目，只有保存成功后才执行丢弃。
为什么操作系统回收站不能完全解决 Git 丢弃问题？
操作系统回收站只能帮助处理作为文件被删除的未跟踪文件；而已跟踪文件的丢弃编辑通常被旧内容原地替换，被移除的版本不一定作为删除文件被系统捕获。
目前 VS Code 对丢弃更改提供了哪些恢复选项？
VS Code 文档说明：丢弃已跟踪文件会恢复其暂存版本或提交版本；丢弃未跟踪文件会删除它，但可通过启用 git.discardUntrackedChangesToTrash 将其移至回收站（需环境支持）。此外可检查时间线本地历史或系统回收站，但均非保证备份。
在命令行中，如何安全地检查即将被丢弃的内容？
可以使用 git status --short 查看工作树状态，git diff 查看未暂存更改，git diff --cached 查看已暂存更改，git clean -nd 预览将被删除的未跟踪路径。这些命令只显示信息，不保存工作。
git stash 能替代回收站吗？
不能完全替代。git stash push -u 可以记录已跟踪更改和未跟踪文件，但它是显式的临时快照，不是自动撤销按钮，且 -u 不包括被忽略文件，-a 则影响更广。
