为什么我们需要它

不得不说，在知道这个命令的时，以及之后的使用中，我都超级热爱这个命令，因为它真的太好用了。

给大家说一下我使用这个命令的场景：

此时我在 feature_666 分支,非常聚精会神加持高专注地实现一个功能 666 模块，简直键盘如飞的编写代码～～～
然后这时，客户反馈出一个 bug , 非常严重，必须立马解决，优先级为 0 ！！！
于是，我需要去到 release 分支去 checkout 新的分支去工作了，但是 666 功能还没完成怎么办？
此时我面临着一个选择题：
A：提交后切换，代码保存到分支 feature_666，却产生一个无意义的提交
B：不提交直接切换，然而这个选项根本没人会选。

是不是很难选，此时，别忘记还有 C 选项！

C：使用 git stash , 将当前修改(未提交的代码)存入缓存区，切换分支修改 bug ,回来再通过 git stash pop 取出来。

1. 暂存操作

#查看当前状态
git status 
#如果有修改,添加修改文件
git add .
#暂存操作
git stash save '本次暂存的标识名字'

2. 查看当前暂存的记录

#查看记录
git stash list

修改存储到什么位置了?

当我们使用 git init给项目添加版本控制的时候，会在项目路径下生成一个 .git 隐藏文件夹。.git 中存储着版本管理的所有信息。
.git/refs/stash 中，存储的是最后一个 stash 对应的节点指针

同样，在 .git/log/refs/stash 中可以看到我们全部的 stash 记录信息

存储多个 stash 的情况

ok ,我们来尝试一下修改文件，然后再次使用 git stash ,此时我们有个两个 暂存修改，那么怎么查看呢？

git stash list //查看暂存区的所有暂存修改记录

如果在未提交的情况下，执行 git stash 两次，无法准确分辨两个stash 具体修改的是哪些内容，这样用，显的伟大的 Git 一点都不智能，怎么可以！。

所以，在这种情况下，给 stash 存储的修改起个名字，显然非常重要，方式如下：

git stash save 

3. 恢复暂存的工作

‘pop命令恢复,恢复后,暂存区域会删除当前的记录'

#恢复指定的暂存工作, 暂存记录保存在list内,需要通过list索引index取出恢复
git stash pop stash@{index}

‘apply命令恢复,恢复后,暂存区域会保留当前的记录'

#恢复指定的暂存工作, 暂存记录保存在list内,需要通过list索引index取出恢复
git stash apply stash@{index}

4. 删除暂存

#删除某个暂存, 暂存记录保存在list内,需要通过list索引index取出恢复
git stash drop stash@{index}
#删除全部暂存
git stash clear