在日常的软件开发过程中，我们常常会遇到这样的场景：你正在一个分支上专注于新功能的开发，代码改了一半，突然线上出现了一个紧急 Bug 需要你去修复，或者同事需要你切换到另一个分支去验证某个功能。这时候，你的工作区处于“脏”状态，既不想提交这些半成品的代码，又无法顺利切换分支。
这正是 Git stash（储藏）命令大显身手的时候。它就像一个临时的“存档点”，允许我们将当前工作区和暂存区的修改临时保存起来，让工作区变回干净的状态，待处理完紧急事务后，再回来恢复之前的工作。
然而，随着开发进度的推进，我们可能会创建大量的 stash。如果不加以管理，这些“存档”就会变成一个混乱的堆栈，我们甚至可能忘记某个特定的 stash 里到底存了什么代码。在本指南中，我们将深入探讨如何列出、查看以及理解 Git 的 stash 历史记录，帮助你成为 Git 进阶用户，让代码管理工作更加高效、井井有条。
目录
- 准备工作：搭建演示环境
- 基础操作：如何列出 Stash 条目
- 进阶查看：显示 Stash 的具体差异
- 深度解析：理解 Stash 的内部结构与日志
- 最佳实践与常见误区
准备工作：搭建演示环境
为了让我们能够直观地看到 Git stash 的历史记录变化，建议你跟随我们在本地终端执行以下步骤。这能帮助你更好地理解命令的输出结果。
- 创建并进入项目目录：首先，我们需要一个干净的 Git 仓库。
# 创建一个新目录并进入
mkdir git_stash_demo
cd git_stash_demo
# 初始化 Git 仓库
git init
- 建立基准提交：我们需要一个初始的提交，以便后续的 stash 有据可依。
# 创建一个新文件
echo "初始文件内容" > demo.txt
# 添加到暂存区并提交
git add demo.txt
git commit -m "初始提交：创建 demo.txt"
- 模拟工作流程：现在，让我们模拟日常工作，进行一些修改并储藏它们。
# 修改文件内容
echo "第一次修改的代码" >> demo.txt
# 查看状态（此时文件处于 Modified 状态）
git status
# 将修改储藏起来
git stash save "第一次储藏：添加了新功能逻辑"
现在让我们再进行一次操作，生成更多的历史记录。
# 再次修改
echo "第二次修改的代码" >> demo.txt
# 储藏第二次修改
git stash save "第二次储藏：修复了特定 Bug"
好了，现在我们的仓库里已经有了两个 stash 记录。接下来，让我们看看如何将这些历史记录“召唤”出来。
基础操作：如何列出 Stash 条目
当我们想要查看到底“存档”了多少次更改时，git stash list 是我们最常用的命令。它是查看 stash 历史的第一步。
基本用法
在终端中直接输入以下命令：
git stash list
这个命令会显示一个 stash 条目的列表，类似于我们查看文件目录一样。输出结果通常如下所示：
stash@{0}: On master: 第二次储藏：修复了特定 Bug
stash@{1}: On master: 第一次储藏：添加了新功能逻辑
输出结果深度解读
这里的输出包含了很多有价值的信息，让我们逐行拆解：
-
stash@{n}：这是 stash 的唯一标识符（索引号）。
* stash@{0} 代表最新的一个 stash（栈顶）。
* stash@{1} 代表倒数第二个，以此类推。这就像一个“后进先出”的堆栈，数字越小越新。
* 实战技巧：当你需要应用或丢弃某个特定 stash 时，可以直接使用这个标识符（例如 git stash show stash@{0}），不需要输入长长的名字。
- 分支信息（如
On master）：
* 这表明该 stash 是在哪个分支上创建的。这在多分支开发中非常有用，可以帮助我们判断该 stash 是否适用于当前分支。
- 提交信息与描述：
* 冒号后面的内容（如 第二次储藏：修复了特定 Bug）是我们在创建 stash 时添加的消息。
* 建议：务必使用 INLINECODEac620609 而不是简单的 INLINECODE962d33ff。清晰的描述能让你在查看历史时一眼看出这个 stash 的用途，避免误删重要代码。
进阶查看：显示 Stash 的具体差异
光看列表有时候是不够的。当我们面对几个名字相似的 stash，或者时间久远忘记了当时改了什么，我们需要深入到 stash 内部，查看它具体包含了哪些文件的修改。这时，git stash show 就派上用场了。
1. 查看简要文件统计
如果我们只想知道这个 stash 修改了哪些文件，以及大致的代码行数变化（不关心具体代码），可以使用基本形式：
# 查看最新 stash (stash@{0}) 的概要
# 这里的 0 是索引号的简写形式
git stash show 0
输出示例：
demo.txt | 1 +
1 file changed, 1 insertion(+)
解释：
这个输出告诉我们，这次 stash 修改了 demo.txt 文件，增加了 1 行代码。这是一种非常快速验证 stash 内容的方式，可以防止我们错误地恢复了一个包含几十个文件修改的大型 stash。
2. 查看详细的代码补丁
如果你觉得上面的信息太少，想要像 INLINECODE37cdb3cd 一样看到具体的代码变更（哪一行加了，哪一行减了），可以加上 INLINECODE70b41e89 或 --patch 参数。
# 显示 stash@{1} 的详细补丁
git stash show -p 1
输出示例：
diff --git a/demo.txt b/demo.txt
index 1234567..abcdefg 100644
--- a/demo.txt
+++ b/demo.txt
@@ -1,4 +1,5 @@
初始文件内容
+第一次修改的代码
1 file changed, 1 insertion(+)
实战价值：
这个命令在代码审查或找回旧代码时极其有用。比如你记得两周前写过一个很酷的正则表达式来处理邮箱验证，后来删掉了。你可以通过 INLINECODE13e79e12 找到那个时间点的 stash，然后用 INLINECODEf1c9ebb4 直接把那段代码“复制粘贴”回来，甚至不需要真正恢复整个 stash。
深度解析：理解 Stash 的内部结构与日志
Git 的 stash 实际上非常聪明，它并不仅仅是保存了文件的差异。如果你是一个追求极致理解的开发者，这部分内容会对你很有帮助。
查看完整的 Stash 日志
除了 git stash list，我们还可以使用 Git 的通用日志命令来查看 stash。因为 stash 在底层实际上也是提交对象。
git log --oneline --graph --all --decorate stash
或者更简洁地查看 stash 队列的日志：
git log -g stash
这个命令会显示 stash 的引用日志。你会发现每个 stash 其实包含两个或三个提交：
- 一个指向工作目录和暂存区之前状态的提交。
- 一个索引状态的提交。
- （如果有）一个未跟踪文件的提交。
为什么了解这个很有用？
当你使用 INLINECODE79b85e32 时，Git 默认显示的是 stash 对应的索引状态（即第2个提交）。有时候你可能会遇到“明明我修改了，但 show 出来的不对”的情况，这通常是因为混淆了工作区状态和暂存区状态。虽然对于日常使用，掌握 INLINECODE7be66968 和 show 已经足够，但理解 stash 是基于提交对象的这一事实，能帮助你更好地理解为什么 stash 会占用空间，以及为什么不能简单地像分支一样操作它。
最佳实践与常见误区
在使用 INLINECODEbcd81da2 和 INLINECODE56d42e38 的过程中，我们也总结了一些实战经验和避坑指南，希望能帮助你少走弯路。
1. 始终使用描述信息
错误做法：
git stash push -m "fix"
当你列表里有 5 个都叫 "fix" 的 stash 时，你会非常抓狂。
正确做法：
git stash push -m "fix: 修复了登录页面在 Safari 下的崩溃问题 [Ticket #1024]"
配合 git stash list 使用时，清晰的描述能极大地降低认知负担。
2. 定期清理 Stash 垃圾
stash 不是用来做永久备份的。如果你发现列表里有几十条记录，甚至几个月前的记录，请及时清理。查看历史后，使用以下命令删除不再需要的 stash：
# 删除特定的 stash
git stash drop stash@{1}
# 或者查看历史后，一次性清除所有
git stash clear
3. 处理未跟踪的文件
默认情况下，INLINECODE5d2a62e0 只会缓存已经被 Git 跟踪的文件（即之前存在过的文件）。如果你新建了一个文件（Untracked file），普通的 INLINECODEf571dfa5 是不会保存它的。
解决方案：
在查看历史时，如果你发现新建的文件不见了，尝试使用 -u 参数来包含未跟踪文件：
git stash save -u "包含新文件的储藏"
git stash show -p stash@{0} # 现在你可以看到新文件的变更了
4. 不要盲目恢复
在执行 INLINECODE321d445e 或 INLINECODEce87319c 之前，务必先使用 git stash show 检查一遍。
很多开发者（包括我们有时赶进度的时候）会直接 INLINECODE63fb1f88 最新的 stash，结果导致当前正在写的代码被瞬间覆盖，产生复杂的冲突。养成先 INLINECODE58edb090 预览，再 apply 的习惯，能挽救无数个不得不手动合并代码的下午。
结论
Git 的 stash 功能远不止是一个简单的“暂存”按钮。通过熟练掌握 INLINECODE51d09202 和 INLINECODE48d37762 这两个核心命令，我们实际上是将 Git 从一个单纯的版本控制工具，变成了一个高效的“工作流管理器”。
我们在本文中探讨了如何：
- 列出历史：使用
git stash list快速定位所有储藏点，利用索引号精准操作。 - 查看详情：使用
git stash show预览文件变更统计，避免盲目操作。 - 审查代码：使用
-p参数查看具体的补丁差异，找回遗失的代码片段。 - 理解本质：通过日志命令理解 stash 的底层结构，做到知其然更知其所以然。
不要让未完成的代码成为切换分支的绊脚石，也不要让堆积如山的 stash 成为技术债务。希望这份指南能帮助你更加自信地在 Git 的历史记录中穿梭，让你的每一次“储藏”和“恢复”都精准无误。现在，回到你的终端，尝试清理一下那些陈旧的 stash 历史吧，保持你的代码仓库像你的思维一样清晰！