在日常工作中，当要经常停下手头的工作区修复临时的BUG，紧急处理来自同事或者经理的请求，但是又不能将手头的工作进行提交的时候。那么Git储藏功能（stash）就起到作用了。
储藏可以捕获我们的工作区状态，允许我们保存工作区当前状态，然后在我们方便时再回到该状态——即所谓的“中断工作流”。
看看下面这个场景：比如正在修改 index.html 文件
这个时候，接到一个BUG修复的任务，要求紧急修复一个编号为8080的bug（当然是要切换到BUG分支来工作了），但是手工上的工作没有完成，不方便进行提交。那么这个时候就用 git stash save 保存 当前的工作状态，然后切换到BUG分支进行操作。
注意：save 是 git stash 的默认操作。执行完 git stash save 操作后，我们的工作区就是干净的了。
现在，bug任务修复完成，现在需要切换到 master 分区来继续我的工作，执行 git stash pop 操作，回到刚才保存的工作状态，继续工作，直到提交版本库
git stash save 操作保存了当前 索引 和工作区 的状态，并且会进行清楚工作以匹配当前分支的头。git stash pop 操作将在当前 工作区 和 索引 中还原最近一次 save 操作的内容。
注意：只能在一个干净的 工作区 中使用 git stash pop 命令。
Git引用日志
引用日志（reflog）记录 非裸版（下面一节远程版本库中会介绍） 版本库中分支头的改变。每次对引用的更新，引用日志都会更新以记录这些引用发生了哪些变化。
可以通过引用日志来追踪操作记录并回溯我们的分支操作，一些会更新引用日志的基本操作包括：
1，复制
2，推送
3，执行新提交
4，修改或创建分支
5，变基操作
5，重置操作
命令 git reflog 用于显示引用日志记录
命令 git reflog show 中的 show 为默认操作，展示了默认引用 即 HEAD 。分支名也是引用，那么 git reflog <branch> 可以显示指定分支的引用日志
每一行都记录了引用历史几种的单次事务，从最新的变更开始倒序显示。最左边的是变更时的提交ID。第二列中类似 HEAD@{7} 的条目为每个事务的提交提供的方便列名， HEAD@{0} 是最新的条目。每一行的冒号后面是对发生事务的描述。
每个像 HEAD@{2} 这样的编号可以作为提交的符号名称，为那些需要提交名的 Git命令 所使用，比如 git show <commit>
所有引用日志都保存在 .git/logs 目录下。.git/logs/HEAD 文件中包含 HEAD 值的历史记录，它的子目录 .git/log/refs/ 包含所有引用的历史记录，其中也包括存储。它的二级子目录 .git/logs/refs/heads 包含分支头的历史记录。
在引用日志存储的所有信息，特别是 .git/logs 目录下的一切内容，归根揭底还是临时的，不那么重要的。就算删除 .git/logs 目录也不会损坏Git的内容数据结构；这只会意味着诸如 HEAD@{4} 这样的引用不会被解析。
