代码写到一半，突然要切分支修个紧急 bug——半成品不想提交，又不舍得丢弃，git stash 就是给这个场景准备的：把工作区的改动整体存进一个栈里，工作区瞬间变干净，处理完别的事再取回来。这篇按"暂存、查看、恢复、清理、untracked 命令与坑"五类整理常用命令，末尾附速查表，完整参数可查 官方 git-stash 文档。
1、暂存修改
存入 stash 时强烈建议带备注，否则列表里全是同名的 WIP，回头根本分不清哪条是哪条。
git stash push -m "登录页改到一半" # 现代写法，带备注
git stash # 最简形式，无备注（不推荐）
git stash save "save message" # 旧式写法，等价于 push -m
推荐统一用 git stash push -m：save 是旧接口，官方文档已标注由 push 取代，且 push 支持指定路径等更多能力。不带备注时 Git 自动生成 "WIP on 分支名" 的消息，多次暂存后很难辨认。
2、查看存储
列表与改动详情是两件事，命令如下：
git stash list # 查看 stash 列表，最新在顶部（stash@{0}）
git stash show # 摘要显示第一条存储改了哪些文件
git stash show -p # 以 diff 形式显示第一条的完整改动
git stash show stash@{1} -p # 指定看第二条的详细改动
编号规则记住一条：stash@{0} 永远是最新存入的，每存一条新的，旧的编号顺移加一。所以跨天回来恢复前，先 list 再 show -p 确认内容，避免恢复错条目。
3、恢复修改
恢复有 apply 与 pop 两条路，区别只在是否删除存储记录。
git stash apply # 恢复第一条，存储记录保留
git stash apply stash@{1} # 恢复第二条
git stash pop # 恢复第一条并从列表删除
git stash pop stash@{1} # 恢复第二条并删除
选择标准很简单：改动取回来还想留个底（或不确定一次能恢复成功），用 apply，确认无误后再 drop；确定就是要一次性取出，用 pop。恢复发生冲突时，存储记录不会被删除，可以处理后重试。
4、清理存储
丢弃单条与清空全部，命令如下：
git stash drop stash@{1} # 丢弃指定存储
git stash clear # 清空全部 stash
clear 是不可逆的整体清空，动手前先 git stash list 过一眼，确认里面没有还想找回的东西。
5、新文件与两个坑
git stash 默认只暂存已被 Git 跟踪的文件修改——新建的 untracked 文件不会被存进去，切回来会发现它还躺在工作区（这通常没问题，但想一起存就要加参数）。
git stash push -u -m "含新文件" # -u 把 untracked 文件一并暂存
千万不要随手加
-a：它会把.gitignore忽略的文件（构建产物、本地密钥配置等）也卷进暂存区，恢复时极易污染工作区甚至引发 丢失 stash 修改的恢复故障，慎用 git stash save -a 一文有完整的翻车实录。
untracked 文件相关的恢复报错（如 "Could not restore untracked files from stash"），多半与 -u 存储的内容和当前工作区同名文件冲突有关，处理思路可参考前面链接的踩坑记录，更多用法总结见 git stash 用法总结和注意点。
6、速查表
五类动作浓缩一张表：
| 场景 | 命令 |
|---|---|
| 带备注暂存（含新文件） | git stash push -u -m "备注" |
| 查看列表 / 详情 | git stash list / git stash show -p |
| 恢复且保留记录 | git stash apply stash@{1} |
| 恢复并删除记录 | git stash pop stash@{1} |
| 丢弃单条 / 清空 | git stash drop stash@{1} / git stash clear |
7、总结
stash 的心智模型就是"工作区的临时存档栈"：push -m 带备注存入、list 加 show -p 先看清、apply 稳妥恢复或 pop 一步取回、drop/clear 收尾清理。三个坑各记一句——新文件要 -u 才会入栈、-a 会把 ignored 文件卷进来千万别用、clear 不可逆先看列表。对于日常多任务切换的开发者，建议把第 6 节速查表存进备忘录，配合分支管理速查一起用，切换现场就再无后顾之忧。
