git stash pop失败是因为其本质是先apply再drop，当apply发生冲突（如工作区有未提交改动或与HEAD变更重叠）时会中止并保留stash，属保护机制；解决后需手动git add和git stash drop。
stash 保存当前修改时，为什么 git stash pop 失败？
因为 git stash pop 本质是先 apply 再 drop，一旦 apply 过程发生冲突（比如工作区已有未提交改动，或 stash 中的变更与当前 HEAD 冲突），pop 就会中止，stash 不会被删除——这是保护机制，不是 bug。
实操建议：
- 优先用
git stash apply测试能否干净还原，成功后再手动git stash drop - 若冲突，Git 会标出冲突文件，解决后
git add+git commit即可，原 stash 仍存在，可反复尝试 - 避免在 dirty 工作区直接
pop；切换分支前确保工作区干净，或用git stash push -u（含未跟踪文件）
stash 和新建临时分支，哪种更适合「中断开发去修 bug」？
取决于改动范围和协作场景：stash 更轻量，适合单人、短时、小范围中断；临时分支更安全，适合多人协作、需 Code Review 或可能持续数小时以上的中断。
关键差异：
-
git stash不产生 commit 记录，不进 reflog，不可被远程共享，丢失风险略高（如误清 stash 列表） -
git checkout -b fix/urgent-bug创建分支后，所有改动都成为真实 commit，可 push 到远程、加标签、关联 issue - stash 默认不保存 untracked 文件，要加
-u；分支天然包含全部工作区状态
切换分支时自动 stash/unstash 的坑在哪？
Git 本身不自动 stash，但某些 IDE（如 VS Code GitLens）或 shell 插件（如 oh-my-zsh git 插件）可能启用自动 stash 功能，容易掩盖真实状态。
GitHub Actions Runtime Regression Audit
下载
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
常见问题：
- 自动 stash 后没提示，切回原分支时又自动 pop，结果和预期不符——尤其当两次切换间有其他操作时
- IDE 自动 stash 可能漏掉
-u，导致 untracked 文件丢失 - CI/CD 脚本里若依赖自动行为，本地和 CI 环境行为不一致，调试困难
建议始终显式控制：git stash push -m "wip: login UI" 比依赖自动逻辑更可靠。
stash 列表混乱时如何快速定位并清理？
执行 git stash list 会显示类似 stash@{0}: WIP on main: … 的记录，但默认不带时间、作者、分支上下文，容易混淆。
高效管理方法：
- 每次 stash 都加描述：
git stash push -m "feat(cart): add quantity selector" - 用
git stash show -p stash@{1}查看具体变更，避免误删 - 清理指定条目：
git stash drop stash@{2}；清空全部：git stash clear（无确认提示！） - stash 实际是 ref，可通过
git reflog stash查看操作历史，恢复误删的 stash（只要 reflog 未过期）
stash 不是垃圾桶，频繁堆叠却不清除，会导致 apply 时冲突概率上升，且难以判断哪条对应哪次中断。
