git stash -u 更常用，因默认 git stash 不暂存未跟踪文件，导致切分支时可能报错；加 -u 后一并暂存已跟踪修改和所有未跟踪文件，覆盖 95% 日常场景。
git stash -u 为什么比 git stash 更常用
因为默认 git stash 不会保存未跟踪文件（untracked files），比如刚新建的 config.local.js、临时日志或调试用的 test-data.json。切分支时 Git 会拒绝覆盖这些文件，导致 git checkout 报错：“The following untracked working tree files would be overwritten”。
加 -u 参数后，它会把已跟踪修改 + 所有未跟踪文件一并暂存。实际开发中，几乎每次都要用它——除非你明确确认当前没新增任何文件。
-
git stash -u：覆盖 95% 的日常场景 -
git stash -a：仅当需要连.DS_Store、.idea/这类被.gitignore忽略的文件也一起藏起来时才用（极少） - 执行前建议先
git status看一眼，确认有没有意外新增的敏感文件（如密钥、本地配置）
git stash list 显示的 stash@{0} 是什么
它不是随机编号，而是栈索引：stash@{0} 是最近一次 git stash 生成的条目，stash@{1} 是上一次，依此类推。Git 用 LIFO（后进先出）管理这个栈，但你可以任意取用其中某一个，不一定要按顺序。
问题在于默认命名太模糊：WIP on main: abc1234 fix login timeout 这种消息在多人协作或一天 stash 多次时根本分不清哪个是支付回调修复、哪个是 UI 调试改的。
- 用
git stash push -m "fix/pay: callback timeout retry"替代git stash，强制带语义化描述 - 支持模糊匹配恢复：
git stash apply stash^{/pay}会找到最近一条含pay的 stash - 避免用
temp、test、xxx这类无意义词；模块前缀（feat/、fix/、chore/）能极大提升可读性
git stash apply 和 git stash pop 的关键区别
git stash apply 是“应用但不删除”，git stash pop 是“应用并删除”。看似简单，但误用会导致混乱：比如 pop 失败（因冲突）后，stash 没删干净，下次又 pop 就可能重复应用同一份修改。
更稳妥的做法是分两步：先 apply，验证没问题再 drop。
- 恢复指定 stash：
git stash apply stash@{1}（而不是apply 1，后者语法错误） - 冲突时，
git status会标出冲突文件，手动解决后git add即可，无需git commit - 想清空整个栈？
git stash clear比反复drop更干脆；但执行前最好git stash list再确认一遍
跨分支应用 stash 时为什么文件没变或冲突一堆
stash 本质是 diff patch，不是快照。它把修改打到当前工作区，不做合并逻辑判断。所以如果目标分支已有同位置改动（比如你 stash 里改了 api.js 第 42 行，而目标分支最新提交也动过这一行），就会直接冲突；如果 stash 里删了某函数，目标分支却新加了同名函数，apply 也会失败。
这不是 bug，是设计使然——Git 不替你做决策。
- 切换分支前，先
git stash -u；切过去后，优先git pull同步最新代码，再apply，减少冲突概率 - 不要在 feature 分支 stash 后，直接
apply到 hotfix 分支——除非你确认这两处修改完全正交 - 最易被忽略的一点：stash 不保存分支上下文，
stash@{0}在 A 分支创建，在 B 分支apply时，Git 完全不管它原本属于哪条线
