git stash 比 -f 更安全，因其将工作区和暂存区更改打包存入栈并可恢复，而 -f 会静默丢弃所有未提交修改且不可逆。
git stash 为什么比 -f 更安全
强制切换（git checkout -f 或 git switch -f）会直接丢弃所有未提交更改，包括已 git add 的暂存内容，且无提示、不可撤销。而 git stash 是真正的“无损”替代——它把当前工作区和暂存区状态打包存入栈，后续可随时恢复。
- 未暂存修改 + 已暂存但未提交的变更 → 全部进入 stash 栈
-
git stash push -m "描述"比裸git stash更可靠，避免因自动命名冲突导致 pop 错位 - stash 不影响未跟踪文件（如新生成的
log、tmp），它们保留在工作区原位 - 执行
git stash pop后若发生冲突，Git 会明确报错（如error: Your local changes to 'file.js' would be overwritten...），而不是静默覆盖
如何用 git stash 实现「带上下文」的分支切换
单纯 git stash + git switch 还不够高效：你得记住哪次 stash 对应哪个分支。真实开发中更推荐组合使用：
- 切换前加语义化标签：
git stash push -m "wip/on-login-flow" - 切过去后，用
git stash list确认最新 stash 是否匹配目标场景 - 恢复时指定 stash：
git stash pop stash@{0}（避免误 pop 别的分支 stash） - 如果只是临时查看某分支，用
git stash apply而非pop，保留 stash 在栈中供多次复用
IDEA / VS Code 中 stash 的隐藏风险
图形界面封装了 git stash，但常忽略两个关键细节：
- VS Code 的 Git 扩展默认执行
git stash，不带-u参数 → 新增但未git add的文件（untracked）不会被 stash，仍留在工作区，可能污染目标分支 - IDEA 的 “Shelve Changes” 功能看似等价，但它把变更存到本地数据库而非 Git stash 栈 → 换机器或重装 IDE 后丢失
- 正确做法：在终端手动运行
git stash push -u（-u包含 untracked 文件），再切换分支 - 若已在 IDE 里点了 stash，务必补查
git status—— 若仍有 untracked 文件残留，说明没真正隔离干净
什么时候不该用 stash，而该直接 commit
stash 不是万能的。以下场景，硬用 stash 反而增加混乱：
- 修改已具备完整功能或修复逻辑（哪怕没写完测试）→ 直接
git commit -m "wip: auth refactor"，比 stash 更易追溯 - 跨天/跨人协作的临时分支 → stash 只存在本地，别人无法获取；而
wip/命名的临时分支可推送到远程共享 - 涉及 submodule 更新或 index 状态敏感操作（如
git update-index --assume-unchanged）→ stash 不保存这些元状态，切回来后行为可能异常 - stash 栈超过 3 层后，
stash@{2}这种索引极易记错，不如用git switch -c wip-fix-xyz新建轻量分支承载
真正无损，不是“不丢数据”，而是让每一步变更都有明确归属和可回溯路径。stash 是工具，不是兜底方案。
