git stash push 是推荐的新语法，因 git stash save 已被标记为 legacy；加 -m 可确保 stash 描述清晰可检索，避免混淆；push -u 才包含未跟踪文件，apply 不删除 stash 而 pop 会，冲突时需手动解决并 git add 后提交。
git stash save 为什么必须加 -m 或用新语法？
不加描述直接 git stash 会生成类似 WIP on main: abc1234 feat: add button 的默认消息，但实际中你可能在多个分支反复 stash，几天后根本分不清 stash@{3} 是哪次改的什么。用 git stash save -m "订单页表单校验未完成" 或更推荐的新语法 git stash push -m "订单页表单校验未完成"，能确保每次记录可读、可检索。
注意：git stash save 已被标记为“legacy”，Git 2.35+ 默认警告，新项目建议统一用 git stash push。
-
git stash push -u才会包含未跟踪文件（如新写的utils/debug.js），默认不存 - 想只暂存部分文件？
git stash push -m "仅UI调整" -- src/components/Button.vue - 如果忘了加
-m，别急着重 stash ——git stash store -m "补个说明" $(git stash create)可事后补，但需慎用
git stash pop 和 git stash apply 的关键区别在哪？
git stash pop = apply + drop，它恢复后自动删掉这条 stash；git stash apply 只恢复不删除。多数场景该用 pop，除非你不确定恢复后是否要保留原 stash 记录（比如想多次尝试合并）。
常见误操作：执行 git stash pop 后报冲突，手动解决完却忘了 git add 和 git commit，结果下次再 pop 还是同一份旧 stash —— 因为第一次其实没成功应用完，Git 检测到冲突就中断了后续的 drop 步骤。
- 恢复指定 stash？先
git stash list看编号，再git stash pop stash@{2} - 想预览某条 stash 改了啥？
git stash show -p stash@{1} - 恢复失败后 stash 还在，别重复
pop，先git stash drop stash@{0}清理再试
遇到 git pull 冲突时，git stash 的典型错误流程
本地有修改，直接 git pull 报错 “You have unstaged changes”，这是 Git 在保护你。但有人会先 git add . && git commit -m "wip" 再 pull，这反而污染提交历史 —— git stash 就是为此设计的干净替代方案。
正确链路是三步原子操作：git stash → git pull origin main → git stash pop。但这里有个隐藏陷阱：如果 pull 后远程更新了你刚 stash 的那些文件，pop 时大概率触发冲突，Git 会在对应文件里插入 <<<<<<< HEAD 和 >>>>>>> Stashed changes 标记。
- 冲突文件必须手动编辑，删掉标记行并保留逻辑正确的代码
- 解决后运行
git add <file>，再git commit（不是git stash pop的后续动作） - 如果冲突太多，先
git stash apply预览，确认无误再git stash drop
.git/refs/stash 里到底存了什么？
所有 stash 都真实存在本地磁盘，路径是 .git/refs/stash（指向最新 stash 的 ref），而每个 stash 实际是三个 Git 对象：一个 commit（工作区快照）、一个 tree（暂存区状态）、一个 parent（当前 HEAD）。这意味着：
stash 不上传远程，不参与 git push，也不出现在 git log 里 —— 它纯粹是本地上下文快照，关机重启后依然存在，直到你显式 drop 或 pop 成功。
- 误删了 stash？只要没执行
git gc，可用git fsck --no-reflogs | grep commit找回 dangling commit，再git stash store恢复 - 团队协作时别指望别人能拿到你的 stash —— 它不共享，也不同步
- 频繁 stash + pop 容易让
stash list堆满，定期git stash clear或按需git stash drop stash@{1}
