要保存带有消息的存储：

git stash push -m "my_stash_name"

或者（自v2.16起已弃用）：

git stash save "my_stash_name"

要列出隐藏内容：

git stash list

所有的储藏物都存储在一个堆栈中。

要弹出（即应用并删除）第n个存储：

git stash pop stash@{n}

使用git stash pop无法按名称弹出（即应用和删除）存储（请参见脚注1）。

要应用第n个存储：

git stash apply stash@{n}

要按名称应用隐藏：

git stash apply stash^{/my_stash_name}

脚注1：

有关申请，请参阅man git stash部分：与pop不同，可以是任何看起来像是由stash push或stash create创建的提交。可能的解决方法（在git版本2.27和2.31上测试）：git stash pop$（git stash-list--prey=“%gd%s”|grep“my_stash_name”|head-1|gawk“｛print$1｝”）

Stashes并不是你想要的永久性的东西。在提交时使用标记可能会更好。构造你想要隐藏的东西。从中进行提交。为该提交创建标记。然后将你的分支回滚到HEAD^。现在，当您想重新应用该存储时，可以使用gitcherry-pick-n标记名（-n是--no commit）。

我怀疑，如果你使用了太多的储藏物（比如说三个以上），那么你就做错了：Stashe通常用于中断工作，而不是实现功能（您可以使用功能分支来实现）。

假设您正在处理某个特性A，然后您发现必须解决的某个问题B（以实现特性A）。那么，您可以这样做：

gitadd——交互式修补特性A的部分，忽略问题B的修复。git将交互式选择提交到当前分支。git隐藏未提交的更改（修复问题B）返回主分支或主分支，可能检查新分支以解决问题B。git stash在当前分支中弹出问题B的修复程序并提交它们。如果存储需要手动合并，则可能会丢弃git存储。返回到特性A分支，并将其重新放置在具有问题B修复程序的分支上。然后，您就没有剩余的存储空间了，但在不同的分支上仍然具有特性A和问题B的修复程序。

您也可以先提交问题B的修复，然后隐藏特性A的更改，但您得到了这个想法。

如果你觉得足够重要，你可以把一个藏起来的东西变成树枝：

git stash branch <branchname> [<stash>]

从手册页：

这将从最初创建＜stash＞的提交开始创建并签出一个名为＜branchname＞的新分支，将＜stash’中记录的更改应用于新的工作树和索引，然后如果成功完成，则删除＜stash〕。当没有给出＜stash＞时，应用最新的一个。

如果运行git-stash-save的分支发生了足够的变化，导致git-stash-apply由于冲突而失败，那么这非常有用。由于在运行git stash时，stash应用于HEAD提交之上，因此它恢复了最初的stash状态，没有冲突。

您可以稍后将此新分支重新放置到其他位置，该位置是您存放时所在位置的后代。

自2.15.x/2.16起，git stash save已被弃用，您可以使用git stass push-m“message”

您可以这样使用：

git stash push-m“消息”

其中“message”是你的留言。

为了检索存储，您可以使用：git存储列表。这将输出如下列表，例如：

stash@{0}: On develop: perf-spike
stash@{1}: On develop: node v10

然后，只需使用apply为其提供存储@{index}：

git stash apply 1

工具书类git存储手册页

如果您只是在寻找一种轻量级的方法来保存当前工作副本的部分或全部更改，然后稍后再重新应用它们，请考虑使用修补程序文件：

# save your working copy changes
git diff > some.patch

# re-apply it later
git apply some.patch

时不时地，我会想我是否应该为此使用储藏室，然后我会看到上面的疯狂，我对自己的所作所为感到满意：）