git stash 是专为临时保存未提交修改而设计的命令，它将工作区和暂存区改动压入栈中，不产生提交、不影响分支状态，支持带消息保存（-m）、包含未跟踪文件（-u）或忽略文件（-a），可用 pop（恢复并删除）或 apply（仅恢复）取回，恢复前应先用 list 查看并确认目标 stash。
git stash 是最直接的保存方式
当你在当前分支有未提交的修改，又想切到其他分支工作，git stash 就是专为这个场景设计的命令。它把工作区和暂存区的改动打包压入一个栈，不产生任何提交，也不影响当前分支状态。
执行后立刻能安全运行 git checkout 或 git switch：
git stash git switch feature/login
- 默认只 stash 工作区 + 暂存区（
git add过的）改动；如果还有未add的新文件，它们不会被包含 - 加
-u参数可包含未跟踪文件：git stash -u - 加
-a可包含忽略文件（慎用，比如node_modules会被一并 stash） -
git stash push -m "wip: api timeout handling"推荐带消息，方便后续识别
stash 后怎么找回修改
切完分支干完活，回到原分支后，用 git stash pop 恢复最近一次 stash 并从栈中移除；用 git stash apply 则只恢复不删除，适合多次应用同一份 stash。
常见误操作：在另一个分支上执行 git stash pop —— 它会尝试把 stash 内容打到当前分支，可能引发冲突甚至覆盖错误内容。
- 先用
git stash list看有哪些 stash，格式类似stash@{0}: WIP on main: abc1234 fix login button - 指定恢复某次 stash：
git stash pop stash@{1} - 恢复时发生冲突，Git 会像 merge 一样标出 git add +
git stash drop清理
替代方案：用临时提交（commit）更可控
如果修改已较完整、逻辑自洽，或者你习惯“每个 commit 都可运行”，直接 git commit -m "WIP: xxx" 提交，再 git switch 切换，比 stash 更透明、更易追溯。
后续回到该分支，用 git reset HEAD~1（软重置）撤销提交但保留修改，或 git commit --amend 合并进前一个提交。
- 临时提交不会推送到远程，除非你手抖执行了
git push - 相比 stash，临时提交能被
git log和 IDE 的历史视图看到，调试时更容易定位上下文 - stash 在跨 clone 或重装 Git 时可能丢失（它存在本地 reflog 中，非正式对象），而 commit 是 Git 对象数据库的一部分，更持久
别用 git checkout -b 新建分支来“绕过”stash
有人以为 git checkout -b temp-save 能把当前修改带到新分支，其实这只是创建了一个指向当前 HEAD 的新分支指针，所有未提交修改仍在工作区——本质没解决“切换分支”的需求，反而多出一个无意义分支。
而且如果之后在新分支上提交，那些修改就真变成那个分支的历史了，容易混淆主干开发节奏。
- 真正需要的是“暂存修改 → 切分支 → 恢复”，不是“换个分支名继续改”
- 如果真要保留修改并换分支继续开发，正确做法是：先
git stash，再git switch -c new-feature，最后git stash pop - IDE（如 VS Code、JetBrains）的分支切换弹窗底层调用的也是
git stash，不是靠新建分支实现的
stash 不是银弹：它不记录文件权限变更、不处理子模块状态、对符号链接支持有限。如果你的修改涉及这些边缘情况，临时提交仍是更稳妥的选择。
