TRAE-AI编程
你正在一个分支上改到一半，突然要切去修紧急 bug，但手上的改动还没写完不能提交，怎么办？Git 储藏改动有 3 种常用做法：用 git stash 一键暂存工作区、用 git stash pop 恢复并删除储藏、以及用 git stash branch 在新建分支上恢复。选错方式最常见的问题是 pop 时和当前改动冲突、或者储藏被误删找不回。本文以 Git 2.x 为例，从最小场景讲到三种用法的边界与常见失败，并给出一份实操清单，下次临时切走前照着做就行。
先看结论
| 你的意图 | 命令 | 注意点 |
|---|---|---|
| 临时收起未提交改动 | git stash |
默认只收跟踪文件，新文件要加 -u |
| 恢复最近一次储藏 | git stash pop |
会删除该储藏，冲突需先解决 |
| 在干净分支上恢复 | git stash branch 新分支 |
避免和当前改动打架 |
一句话：临时切走用 stash 收起，回来用 pop 取回；如果当前工作区已经不干净，用 stash branch 在新分支上恢复最稳。
一、最小场景与预期结果
假设你正在 feature 分支改一个文件，改到一半被叫去修紧急 bug。先确认当前状态：
git status
# 预期：有 modified: xxx.js 等未提交改动
git stash # 把当前改动收进储藏栈
git status
# 预期：工作区变干净，可以安全切分支
git checkout main
先过一遍 Git 教程 理解工作区、暂存区、版本库三层关系，Git 储藏改动本质就是把"工作区+暂存区"的差异临时压入一个栈。实操清单：stash 后先 git status 确认工作区干净，再切分支；回来前先 git checkout feature 回到原分支，再决定 pop 还是 apply。这一步的预期是：stash 后工作区回到上次提交状态，你可以毫无负担地切走。
二、方法一：git stash 与 git stash pop 基础用法
最稳的 Git 储藏改动流程就是 stash 收起、忙完再 pop 取回。
git stash # 收起跟踪文件的改动
# 切去修 bug、提交、切回 feature
git checkout feature
git stash pop # 恢复最近一次储藏并把它从栈中删除
命令与运行：执行 git stash pop 后预期改动回到工作区，且 git stash list 里那条记录消失。检查：若 git stash list 仍显示该条，说明 pop 遇到了冲突、未被删除，需先解决冲突再处理。失败处理：默认 stash 不收"新增但未跟踪"的文件，需要 git stash -u 或 git stash -A 才把新文件一起收；pop 时如果当前工作区已有冲突改动，Git 会报冲突，此时储藏不会被删除，解决冲突后再 pop 即可。常用参数可查 Git 速查手册 里的 stash 章节。操作清单：stash 前先 git status 看清哪些是未跟踪文件，避免新文件被漏收；pop 前先 git stash list 确认栈里至少有一条，空栈 pop 会报错。
三、方法二：git stash list / apply / drop 精细化管理
当你不止一次 stash，就需要区分"恢复哪一条"以及"恢复后留不留"。
git stash list # 查看所有储藏，形如 stash@{0}
git stash apply stash@{1} # 恢复指定一条，但不删除
git stash drop stash@{1} # 单独删除一条
git stash show -p stash@{0} # 查看某条储藏具体改了什么
运行预期：git stash list 列出所有储藏；apply 后改动回来但记录还在；drop 后记录消失。把"恢复哪一条、恢复后留不留"想清楚，再决定用 apply 还是 pop。检查：用 git stash show -p 确认内容再决定删哪条。失败处理：apply 和 pop 的区别就在"删不删"——apply 恢复后储藏还在，方便多次复用；pop 恢复同时删除。误删一条储藏后，在 2.x 里通常已无法找回，所以重要改动优先用 apply 而非直接 pop。
四、方法三：git stash branch 与边界避坑
当储藏是基于旧提交做的，而你现在的分支已经前进，直接 pop 极易冲突。最安全的做法是在新分支上恢复：
git stash branch hotfix-from-stash stash@{0}
# 预期：创建并切换到 hotfix-from-stash，把储藏内容恢复进去，冲突会在新分支里解决
这条命令会新建分支、把储藏恢复进去、成功后自动删除该储藏。运行预期：你处在一个干净的新分支上，储藏内容已就位。检查：git stash list 中该条已消失即为成功。失败处理：关于"恢复后怎么撤销"可对照 Git Magic 教程 的栈与分支章节，它讲清了储藏栈与提交对象的内部结构。其价值在于：冲突只发生在一个全新分支里，不会污染你正在用的分支，解决完再合并回去即可。
边界、反例与常见失败一并放在这里：
- 新文件没被收走：忘记
-u，切回来发现新文件"丢了"（其实没丢，只是没进储藏）。统一用git stash -u收起全部改动。 - pop 冲突：当前工作区已有同名改动时 pop 会冲突。先提交或 stash 当前改动，再用
git stash branch隔离恢复。 - 误 drop 找不回：2.x 的 drop 不可逆，重要储藏用
apply保留，或先git stash show -p确认内容。 - 储藏栈混乱：多次 stash 后分不清哪条对应哪次工作，建议每次
git stash save "修复登录的半成品"加说明。
总结
Git 储藏改动有 3 种常用做法，选型看场景：
- 临时切走又回来，用 git stash + git stash pop 最顺手；
- 多次储藏要挑着恢复，用 git stash list / apply / drop 精细管理；
- 怕冲突或分支已前进，用 git stash branch 在新分支上恢复最稳。
记住默认 stash 不收新文件，重要改动优先 apply 保留，储藏栈就不会变成"丢改动"的坑。
延伸学习
想把这块知识系统补齐，可以按这个顺序来：
- 想跟着课程动手练，Git 入门实战课程 是边学边写的形式；
- 看回退与恢复的安全操作，Git 怎么回退到上一个版本笔记 适合延伸阅读；
- 需要更完整的命令参考，Git 官方中文手册 适合随时查阅。
常见问题
Q：git stash 和 git commit 临时提交有什么区别？
A：stash 把改动压进一个临时栈，不进入提交历史，适合"马上回来"的短暂停顿；commit 会生成正式提交，适合"改动已经成型、想留痕"。如果改动还要继续写，用 stash 更干净，不会污染提交记录。
Q：git stash pop 冲突了怎么处理？
A：先别慌，冲突只发生在工作区。打开冲突文件解决标记后 git add，再 git stash drop 删掉那条储藏即可。若不确定，优先用 git stash branch 新分支名 在干净分支上恢复，冲突隔离在分支里更好处理。
Q：git stash 后切回原分支，改动去哪了？
A：改动还在储藏栈里，没丢。用 git stash list 能看到 stash@{0}，git stash pop 或 git stash apply 就能取回。只要没执行过 git stash drop 或 git stash clear，储藏会一直保留。
Q：stash 能保存几次？会不会把栈撑爆？
A：stash 是一个栈，可以连续 stash 多次，每次生成 stash@{0}、stash@{1}… 无限叠加。但栈里堆太多容易分不清哪条对应哪次工作，建议每次用 git stash save "修了登录的半成品" 加一句说明，或者清掉不再需要的条目，保持栈清爽。日常维护可用 git stash clear 一次性清空整个栈，但清空前务必确认没有还要的改动，清空后很难找回。
