在开发中途遇到紧急 Bug 时，最推荐的做法是先用 git stash 保存当前未完成的工作现场，再创建临时分支修复 Bug，两者配合使用而非二选一。
先说结论：stash 用于临时储藏未提交的修改，临时分支用于隔离 Bug 修复环境，标准流程是先 stash 后建分支。
- 适合：开发任务未提交但需立即切换分支修复紧急问题的场景
- 重点看：stash 保存的是工作区和暂存区变更，分支是代码隔离的载体
- 别忽略：恢复现场后需检查冲突，临时分支合并后应及时删除
核心区别：stash 与临时分支
标题提到的两者并非互斥关系，而是不同维度的工具。Stash 是临时栈，分支是历史线。
| 特性 | git stash | 临时分支 (Temporary Branch) |
|---|---|---|
| 存储位置 | 本地栈区 (不提交) | 本地分支历史 (可提交) |
| 持久性 | 低 (清理后丢失) | 高 (合并前永久存在) |
| 适用场景 | 短时切换 (几分钟到几小时) | 需协作或修复耗时较长 |
| 恢复命令 | git stash pop | git checkout |
标准实操流程
以下是处理紧急 Bug 的标准命令序列，兼容 main/master 分支习惯：
1. 保存现场：git stash
2. 切换主分支：git checkout main (或 master)
3. 创建临时分支：git checkout -b issue-119
4. 修复并提交：git add . 然后 git commit -m "fix bug"
5. 合并并删除：git checkout main 接着 git merge `--no-ff` -m "merge bug fix" issue-119 最后 git branch -d issue-119
6. 恢复现场：git checkout dev 然后 git stash pop
冲突处理与验证
执行 git status，确认工作区显示干净（nothing to commit, working directory clean）后再切换分支。恢复现场后，再次执行 git status，应能看到之前未提交的文件修改恢复如初。
stash pop 冲突解决步骤：
若 git stash pop 提示冲突，不要强制覆盖，按以下步骤处理：
1. 查看冲突文件：git status 显示哪些文件冲突。
2. 手动编辑文件：解决冲突标记（<<<<<<< 等）。
3. 标记解决完成：git add .
4. 清理 stash 记录：冲突解决后，stash 记录仍保留在列表中，需手动删除 git stash drop 或 git stash drop stash@{0}。
使用 git stash list 检查，若使用 pop 命令且无冲突，列表中应不再显示该条 stash 记录；若冲突解决后，需确认列表已清理。
常见风险与清理
1. 忘记删除临时分支：临时分支合并后若不删除，会导致分支列表杂乱，建议合并后立即执行 git branch -d 删除。
2. 误删未保存的现场：stash 内容若未 apply 或 pop 就被 drop 或清理，修改将丢失。重要修改建议先 commit 到临时分支再切换，而非仅依赖 stash。
3. 误以为 stash 是提交：stash 只是临时储藏，不会生成 commit 哈希，重启或清理后可能丢失，不能作为永久备份。
4. 分支命名习惯：新仓库默认主分支可能是 main 而非 master，执行切换前请用 git branch 确认主分支名称。