- 要临时切任务但不想立刻提交的人
Command Reference
git stash 教程
解释如何用 git stash 临时保存未提交改动，并在后续恢复、查看和清理 stash 条目。
- 知道 stash 默认不等于完整备份
- 知道 apply 和 pop 的区别
- 误以为 stash 会自动保存一切
- 长期堆积 stash 导致上下文难以追踪
一句话理解
git stash 用于把当前未提交的工作状态临时搁置起来，让你先切换任务，再回来继续。
当前工作区edited files
stash push
stash 栈stash@{0} / stash@{1}
apply / pop
恢复后继续resume work
把 stash 想成“临时寄存处”会更准确。它的价值在于帮你处理中断，而不是替代分支或长期保存重要状态。
适合什么场景
- 正在写一半，需要紧急切到别的分支
- 改动还不适合提交，但你必须先清理工作区
- 想快速保存实验状态，再决定是否继续
最常见操作
临时保存当前改动
git stash push -m "wip: login form"
查看已有 stash
git stash list
恢复最近一次 stash
git stash apply
恢复并删除该 stash
git stash pop
查看 stash 里的具体改动
git stash show -p stash@{0}
进阶但很常用的两种写法
把未跟踪文件一起 stash 进去
git stash push -u -m "wip: include new files"
如果你只执行普通 stash，新建但未跟踪的文件往往不会被带进去。
只 stash 部分路径
git stash push src/checkout.ts
apply 和 pop 的区别
apply：恢复，但保留 stash 记录pop：恢复，并在成功后删除 stash 记录
如果你还不确定恢复结果是否正确，优先用 apply 更稳。
图里这一步之所以特别标成 apply / pop，就是因为很多误用都发生在这里。pop 很方便，但它会把“恢复”和“尝试删除 stash”绑在一起，所以对重要改动更稳的顺序通常还是先 apply。
一个更稳的恢复顺序
很多人习惯直接 pop，但更稳的顺序通常是：
git stash listgit stash show -p stash@{0}git stash apply stash@{0}- 确认改动无误后再
git stash drop stash@{0}
一个常被忽略的点
stash 不是长期存档方案。它更像短期缓存区，不适合长期堆积重要变更。
stash 恢复时为什么也会冲突
因为 stash 不是“冻结整个世界”，它只是把当时的一组改动记录下来。等你恢复时，当前分支代码上下文可能已经变了，所以 apply 或 pop 仍然可能冲突。
两个实用习惯
习惯 1：总是写 message
git stash push -m "wip: checkout flow"
这样后续回看 git stash list 时更容易知道每个条目在干什么。
习惯 2：优先 apply，确认无误后再删除
对重要改动，apply 比 pop 更稳。
常见误区
误区 1：stash 可以替代分支
不建议。需要持续开发或协作的工作，更适合显式分支。
误区 2：stash 一定不会冲突
不是。恢复 stash 时，如果代码上下文已经变化，仍然可能产生冲突。
误区 3：stash 越多越说明我保存得越安全
通常相反。stash 太多往往说明工作切换策略不清晰，恢复成本和遗忘风险都在上升。
实践建议
如果 stash 条目开始越来越多，说明你可能需要：
- 更频繁的小提交
- 更清晰的分支切换策略
- 把短期实验显式转成分支而不是一直堆在 stash 里
一个实用判断原则
- 临时切任务、稍后马上回来：stash 很合适
- 需要保留几小时到几天并继续演进：更建议建分支
- 涉及团队协作或 review：优先提交到分支，而不是藏在 stash 里
这条命令在流程里解决什么问题
git stash 解决的是"手头有未完成的改动但需要立即切换任务"的问题。它把当前的工作区和暂存区改动临时保存到一个栈中，清空工作区以便切换到其他分支，之后再恢复改动继续工作。
典型用例
- 正在开发一个新功能写了一半，突然需要切换到 main 分支修一个紧急 bug，用
git stash push暂存当前改动，切分支修完后再git stash pop恢复。 - 想尝试一个实验性的改动但不确定是否保留，先 stash 起来，验证完再决定是否 apply 回来。
- pull 或 merge 前工作区有未提交改动导致冲突，先 stash 清空工作区，完成 pull 后再恢复改动。
图例理解
未提交的修改暂存区内容未跟踪文件(需-u)
干净的工作区stash 栈条目可恢复的改动快照
stash 是短期缓存区，不适合长期堆积重要变更。重要改动应该提交到分支。
特殊情况与边界
- stash 不是长期存档方案。它更像短期缓存区，不适合长期堆积重要变更——stash 太多会增加恢复成本和遗忘风险。
- 恢复 stash 时（apply 或 pop），如果当前分支代码上下文已变化，仍然可能产生冲突。
- 默认 stash 不包含未跟踪文件，需要显式加
-u或-a才能把未跟踪文件也一并保存。 pop会在恢复成功后删除 stash 记录，而apply保留记录。对重要改动优先用apply，确认无误后再drop。- stash 条目是局部存储，不会随 push 同步到远程，换机器后无法恢复。
跟着做一遍
stash 最容易出问题的地方，不是保存，而是恢复。这个练习就是要把“先看、先 apply、再删除”的顺序变成肌肉记忆。
git switch -c lab/stash-demo # 修改一个已跟踪文件，再新建一个未跟踪文件跟着做
- 执行 `git stash push -u -m "wip: stash demo"`。
- 运行 `git stash show -p stash@{0}` 看清里面到底保存了什么。
- 先用 `git stash apply stash@{0}` 恢复，再确认无误后决定是否 `git stash drop stash@{0}`。
- 你会看到未跟踪文件只有在 `-u` 时才会一起进入 stash。
- `apply` 会恢复现场但保留 stash 记录。
- 确认无误后再 drop，比直接 pop 更保守。
- 如果这份工作会持续几小时甚至几天，通常应该建分支而不是长期堆 stash。
- 如果还没看过 `stash show -p`，就别急着 pop。
- 恢复后有冲突并不代表 stash 坏了，通常只是当前代码上下文变了。
继续学习建议
推荐继续阅读：
git resetgit restoregit clean