git stash 保存的是工作区和暂存区的修改，不包括未跟踪文件；默认只处理已跟踪文件的 staged 和 unstaged 变更，新建未 add 的文件（如 .env.local）需加 -u 参数才被暂存。
stash 保存的是什么，不是所有修改都会被存
git stash 默认只保存 git status 中显示为 “modified” 和 “staged” 的文件，不包括未跟踪（untracked）的新建文件。如果你刚新建了 config.local.js 但没 git add 过，执行 git stash 后它依然会留在工作区——这常导致切换分支时冲突或误删。
- 要一并保存未跟踪文件，必须加
-u参数：git stash push -u - 如果只想暂存部分改动（比如只 stash 某几个文件），先
git add那些想保留的，再用git stash --keep-index，这样已暂存的内容不会被 stash 走 -
git stash本质是创建一个临时 commit，然后把工作区和暂存区都重置到 HEAD，所以 stash 记录里包含“当时暂存区状态”，这点影响后续git stash pop行为
pop 失败时别急着硬来，先看冲突位置
执行 git stash pop 报错 “error: Your local changes to the following files would be overwritten by merge”，说明 stash 中的修改和当前工作区有重叠，Git 拒绝自动覆盖——这不是 bug，是保护机制。
- 先运行
git stash show -p看这个 stash 改了哪些行，心里有数 - 用
git stash apply替代pop，它只应用不删除 stash，方便出问题后回退 - 如果冲突在非关键文件（如日志、临时配置），可手动删掉再
git stash pop；若真要合并，建议先git stash branch tmp-branch，新开分支处理，避免污染当前上下文
多个 stash 怎么区分，别只靠编号猜
git stash list 默认只显示 stash@{0}、stash@{1} 这种编号，但不同终端、不同操作（比如 git pull 触发的自动 stash）会让顺序飘忽，靠数字极易拿错。
- 每次 stash 都加描述：
git stash push -m "wip: api timeout retry logic"，之后git stash list就能一眼识别 - 查看某次 stash 的具体变更：
git stash show -p stash@{2}，别只看git stash show stash@{2}（后者只列文件名） - 用
git stash drop stash@{1}删除指定项，而不是git stash clear一键清空——后者可能删掉还没用上的调试 stash
stash 不是分支替代品，长期挂起的改动会失效
stash 本质是引用在 refs/stash 下的临时提交，不参与远程同步，也不受分支生命周期管理。如果 base commit 被 rebase 或 force-push 覆盖，对应 stash 可能变成“悬空”，git stash pop 时出现大量冲突甚至 patch 失败。
- 超过 2 天没用的 stash，建议先
git stash apply，再git commit到临时分支，哪怕只是git checkout -b wip/xxx - CI 流程里慎用 stash：某些自动化脚本（如 husky pre-commit）可能触发 stash，但后续没 pop，导致构建环境残留旧状态
- 看到
git stash list里有一堆stash@{n}却记不清用途？说明已经该清理了——stash 是缓冲区，不是归档库
