git stash 是将工作区和暂存区的未提交修改打包为临时提交以安全切换分支，必须用于有未提交改动且需立即切分支时，慎用于含未跟踪文件的场景。
紧急 Bug 出现时，你正在 feature/login 分支上改一半代码，工作区有未提交修改，又不能直接切到 master ——这不是流程问题，是 Git 的默认保护机制在起作用。正确做法不是硬切、不是丢改动、更不是随便 commit 一个“WIP”，而是用明确路径隔离上下文。
git stash 是什么，什么时候必须用它
当你在当前分支有未暂存或已暂存但未提交的修改，而 Git 拒绝让你 git checkout 到其他分支时，git stash 就是唯一安全出口。它不是备份，也不是快照，而是把工作区 + 暂存区的变更打包成一个临时提交，然后还原当前分支到干净的 HEAD 状态。
- 必须用：修改未
git add或只git add了部分文件，且需要立刻切换分支 - 不必用：工作区完全干净（
git status显示 nothing to commit），可直接git checkout master - 慎用：
git stash不保存未被 Git 跟踪的新文件（untracked files），如新建的config.local.js，需加-u参数：git stash -u
从 master 创建 hotfix 分支的正确命令顺序
修复必须基于最新 master，否则补丁可能漏掉已有变更，或引入重复冲突。跳过 git pull 直接 git checkout -b hotfix/auth-202607 是常见错误。
- 先确保本地
master是最新的：git checkout master && git pull - 再创建并切换：
git checkout -b hotfix/auth-202607（分支名带日期和简短描述，便于识别和清理） - 不要用
git branch+git checkout两步，容易漏切；-b是原子操作 - 如果远程
master有新提交，而你本地没拉，hotfix分支会基于旧 commit，后续 merge 时可能多出无意义的冲突
修复完怎么合并，为什么不能直接 merge 到 dev
热修复的目标是尽快上线，所以第一优先级是进 master，而不是进开发分支。直接 git merge hotfix/auth-202607 到 dev，会导致未测试的功能代码提前混入修复逻辑，破坏测试环境稳定性。
- 先合入
master：git checkout master && git merge --no-ff hotfix/auth-202607（--no-ff保留分支结构，方便追溯） - 再推送到远程：
git push origin master - 最后同步回
dev（不是必须立即做，但建议在下次日常合并前）：git checkout dev && git merge hotfix/auth-202607 - 如果
dev已有其他人提交，merge 可能触发冲突，此时应由dev维护者处理，而非热修复发起人
恢复原分支后 git stash pop 失败怎么办
git stash pop 失败通常不是命令错，而是上下文变了：比如你 stash 后，feature/login 分支被别人 rebase 过，或者你手动改过同一文件的相同行 —— 这时 Git 无法自动合并，会中止并提示 conflict。
- 先看 stash 内容：
git stash show -p，确认改了哪些文件和行 - 用
git stash apply替代pop，它只应用不删除，失败后 stash 记录还在，可重试 - 冲突文件会标为
both modified，手动编辑解决后git add <file></file>，再git stash drop手动删掉已用过的 stash - 多个 stash 时，
git stash list会显示类似stash@{0}，可用git stash pop stash@{1}指定恢复某一条
真正容易被忽略的点不在命令本身，而在分支命名和清理习惯：热修复分支用完不删，三个月后列表里堆满 hotfix/xxx，没人记得哪个修过什么；git stash 留着不清理，某天 git stash list 输出十几条，根本分不清哪条对应哪次中断。留痕要轻，收尾要净。
