git stash save 是临时存档未提交修改的弃用命令，应改用 git stash push -m；它不进 commit 历史，清空后即丢失，适用于未完成开发需切分支场景。
Git stash save 不是保存“永久备份”，而是临时存档当前未提交的修改，方便切分支或处理紧急任务；它不会记录在 commit 历史里，stash 列表清空后就彻底丢失。
什么时候该用 git stash save 而不是直接 commit？
当你改了一半代码，但还没法形成逻辑完整的 commit（比如功能没写完、测试没过、不想污染当前分支的提交历史），又必须切换分支去修 bug 或拉新代码时，git stash save 就是唯一轻量的选择。
直接 commit 临时改动会带来两个问题：一是后续 rebase/cherry-pick 时容易误带这些“脏 commit”；二是别人看历史会觉得提交信息混乱（比如写 “wip”、“temp fix” 这类非语义化信息）。
- 你正在 feature 分支上开发，但
main上有个高优 hotfix 需要立即拉下来测试 - IDE 报错说 “working directory not clean”，而你又不想丢弃未完成的调试代码
- 想快速验证某个旧 commit 是否复现问题，但当前工作区有大量未暂存/未跟踪文件
git stash save 和 git stash 有什么区别？
从 Git 2.19 开始，git stash 默认等价于 git stash push，而 git stash save 已被标记为“deprecated”（不推荐使用），只是出于兼容性还保留着。它俩行为几乎一样，但关键差异在参数支持：
-
git stash save "msg"支持直接加描述（但只存到 stash 栈顶的 comment 字段，不进 reflog） -
git stash push -m "msg"是当前推荐写法，支持更多选项，比如-u（包含未跟踪文件）、--include-untracked、--keep-index等 - 如果你运行
git stash save -u，Git 会报错：“unrecognized argument: -u” —— 因为save不支持这个 flag
所以，别再用 save，统一改用 git stash push -m "fix login UI temporarily"。
恢复 stash 时最常踩的三个坑
很多人以为 git stash pop 就是“还原 + 删除”，其实它失败时不会自动删除 stash，但也不会提示你冲突已发生——表面看起来像啥都没做，实际可能已部分合并出错。
- 执行
git stash pop后文件没变？先跑git status，很可能有 merge conflict 标记但被忽略 - 用
git stash apply恢复后忘了手动git stash drop，导致 stash 列表越积越多（git stash list可查） - 在错误分支上
pop了 stash：比如 stash 是在feature/login上做的，却切到main执行 pop，Git 会强行合并，极可能破坏当前分支状态
稳妥做法是：先 git stash list 确认目标 stash（如 stash@{0}），再用 git stash pop stash@{0} 显式指定，避免歧义。
真正麻烦的不是 stash 本身，而是 stash 中混入了编辑器自动生成的临时文件（比如 .swp、.DS_Store）或者构建产物（node_modules/）。这类文件一旦被 stash，下次 pop 时可能覆盖掉你刚删掉的干净目录。建议把它们写进 .gitignore，再加个 git clean -fd 定期清理工作区。
