• 文档
• 教程
• 知识库

在日常开发中，git stash常被用来暂存尚未完成的工作，以便在分支切换、变基（rebase）或拉取远端更新时保持工作区干净。但当 stash 列表越积越长、里面存放的改动早已失去价值时，逐个删除既繁琐又低效。本篇指南以 til 仓库中的 clear-entries-from-git-stash.md 为核心，完整讲解如何通过git stash list、git show stash@{n}核查 stash 内容，用git stash drop stash@{n}精准删除单条记录，以及用git stash clear一次性清空整个 stash 列表，并附带误清空后的恢复思路与同仓库相关笔记索引。读完本文，你将掌握 stash 从创建、查看、定向删除到整体清空的完整操作链路。

一、什么时候会积累下一堆无用 stash

在开发流程中，stash 的典型产生时机包括：

• 切换分支前：工作区有未完成的改动，又不想提交半成品，先git stash暂存；
• 变基或合并前：执行git rebase、git pull之前，把本地改动暂时移开；
• 调试其他问题：临时放下当前任务，转向修复另一个 Bug 或验证某个实验性改动。

大多数情况下，这些 stash 会在几分钟后被git stash pop恢复。但正如原文档指出的，"有时这些被暂存的改动会被时间遗忘"（"sometimes these stashed changes are abandoned to time"）——它们静静地躺在 stash 列表里，既没有价值，又干扰视线，甚至占据本不该占据的存储空间。

值得留意的是，git stash默认只暂存已跟踪文件的改动。若想一并暂存未跟踪文件，可使用--include-untracked；若连.gitignore忽略的文件也要纳入，则用--all。仓库中的 stash-everything.md 记录了一个真实教训：作者对包含node_modules的目录执行带--all的 stash，命令卡了约 10 秒，把整个依赖目录都塞进了 stash。这也是 stash 条目容易快速膨胀、最终需要整体清理的诱因之一。

二、清空前先看清家底：git stash list与git show stash@{n}

在决定"全部清空"之前，务必先确认 stash 列表里到底有什么。原文档给出的核查路径分两步：

第一步，列出所有 stash 条目：

$ git stash list stash@{0}: WIP on master: 6766419 Add link to source for latest TIL stash@{1}: On master: made some changes stash@{2}: WIP on develop: 1a2b3c4 Fix typo in README # ... 共 9 条

每条记录都以stash@{n}形式引用：stash@{0}是最新的一条，序号随创建时间递减。默认情况下，Git 会用当前分支名 + 最近一次提交的 SHA 及其首行提交信息作为条目描述，例如上例中的WIP on master: 6766419 Add link to source for latest TIL。这种自动生成的上下文通常比较模糊，如果希望日后能快速识别，可以在创建时用-m自定义消息：

$ git stash push -m 'made some changes'

自定义后列表会显示为On master: made some changes，可读性大幅提升。更详细的写法见仓库中的 include-a-message-with-your-stashed-changes.md。

第二步，逐条查看具体改动内容：

$ git show stash@{0} $ git show stash@{1}

git show会把指定 stash 条目对应的完整补丁（diff）输出出来，帮助你判断里面到底是值得保留的代码，还是早已废弃的实验改动。原文档作者正是这样检查了最新的两条（stash@{0}与stash@{1}），确认"没有一条是我在意的"，才决定走"全清"路线。

补充技巧：git stash show是 Git 内置的、更省敲击的查看方式，可以不带花括号引用直接写序号，例如git stash show 1等价于查看stash@{1}，省略序号则默认展示最新的stash@{0}。仓库中的 show-what-is-in-a-stash.md 对此有专门说明。如果想从某个 stash 中单独捞回某一个文件，还可以用git checkout stash@{1} -- README.md这类写法，详见 grab-a-single-file-from-a-stash.md——也就是说，在整体清空之前，你可以先把仍需要的文件从 stash 里抢救出来。

三、只删一条：git stash drop stash@{n}

如果核对后发现只有少数几条是废弃物，不必动刀全部清空。Git 提供了精准删除单条 stash 的命令：

$ git stash drop stash@{0}

执行后，stash@{0}会从列表中移除，其余条目的编号自动前移（原stash@{1}变为新的stash@{0}）。这在原文档中被描述为"我可以去掉那些单独的条目"（"I can get rid of those individual entries with, say,git stash drop stash@{0}"）。

由于编号是动态前移的，连续删除时建议每次重新git stash list核对当前编号，避免误删。

四、一键清空：git stash clear

当确认 stash 列表里没有任何值得保留的条目时，逐个drop就显得低效了。此时直接清空整个列表：

$ git stash clear

命令执行后不会有任何成功提示。再次运行git stash list，会看到输出为空——这正是原文档记录的最终效果："Now when I rungit stash list, I see nothing."

git stash clear与git stash drop的核心区别在于作用范围：

从 Git 的存储模型看，stash 条目本质上是挂在refs/stash引用下的提交对象（commit object）。git stash clear的作用是移除这个引用对全部条目对象的指向，而不是逐个提交执行 drop。因此：

• 它的操作不可逆，没有确认提示，执行前必须确认列表内容；
• 被清空后，如果你仍然记得某个 stash 对应的提交 SHA，且该提交对象尚未被垃圾回收（git gc），从实现原理上可以推断它仍有机会通过git fsck等底层对象排查手段找回——但这属于"亡羊补牢"式的恢复手段，日常最佳实践仍是清空前三思：先git stash list逐条核对，对仍有价值的条目先git stash show导出补丁、或用git checkout stash@{n} -- <file>抢救出需要的文件，再执行clear。

如果担心误操作，更稳妥的做法是：为确有保留价值的 stash 打上可读性强的自定义消息（git stash push -m '...'），并在列表较长时定期用git stash drop只清理过期条目，把git stash clear留给"确认整条列表皆可废弃"的场合。

五、相关阅读与进一步探索

stash 的完整命令族不止"存、取、删"，同仓库的 git 目录下还有多篇相关笔记可以串联学习：

• stash-everything.md：--include-untracked与--all的边界，以及误 stash 整个node_modules的真实案例；
• include-a-message-with-your-stashed-changes.md：用-m为 stash 添加可识别上下文；
• show-what-is-in-a-stash.md：git stash show的快捷用法；
• grab-a-single-file-from-a-stash.md：用git checkout stash@{n} -- <file>从 stash 中提取单个文件；
• pick-specific-changes-to-stash.md：用--patch交互式挑选要暂存的 hunk；
• interactively-checkout-specific-files-from-a-stash.md：借助 fzf 交互式选择 stash 中的文件进行 checkout；
• accessing-a-lost-commit.md：通过git reflog找回"丢失"提交的通用思路。

更完整的命令语义与边界行为，可随时查阅man git-stash——这也是原文档明确给出的进一步学习入口。

一句话总结：git stash list摸清家底 →git stash show stash@{n}逐条甄别 →git stash drop stash@{n}定点删除 → 确认全部无用后git stash clear一键清场。清空操作不可逆，动手前务必做好核对与必要的文件抢救。

• 文档
• 教程
• 知识库