git stash 不会丢掉未跟踪文件，但默认不暂存；只保存已跟踪且修改的文件及暂存区变更，未跟踪文件被忽略。需加 -u 参数（如 git stash -u）才一并暂存。
git stash 会丢掉未跟踪文件吗
不会自动丢掉，但默认不暂存。执行 git stash 时，它只保存已跟踪（tracked）且被修改的文件，以及暂存区（staged）里的变更。所有 untracked 文件（比如新写的 debug.log 或临时脚本）会被忽略，既不保存也不删除。
如果你需要一并暂存未跟踪文件，必须显式加 -u 参数：
git stash -u
注意：-u 会把 untracked 和 ignored 文件都纳入暂存——如果项目里有大量构建产物（如 node_modules/ 或 dist/），而它们又没被正确写进 .gitignore，git stash -u 可能卡住或暂存一堆不该进 Git 的东西。
- 想安全包含未跟踪文件？先确认
git status中列出的 untracked 项是否真的该暂存 - 更稳妥的做法是：用
git add -N <file></file>把关键新文件“声明”为待跟踪，再git stash - 误用了
-u导致暂存了垃圾文件？用git stash show -p stash@{0}先看内容，再git stash drop删除
stash 后怎么恢复但不删除记录
用 git stash apply，而不是 git stash pop。后者 = apply + drop，前者只应用变更，保留 stash 栈顶条目不变。
典型场景：你 stash 了一堆调试代码，想在另一个分支上试运行，但不确定是否最终要合并进去——这时就得反复 apply / reset，不能让 pop 一气呵成把记录清掉。
- 恢复特定 stash？用
git stash apply stash@{2}（索引从 0 开始） - 恢复时发生冲突？Git 不会中止，而是标记冲突块，像普通 merge 冲突一样手动解决
- 想看看 apply 前后差异？先
git stash show -p，再apply
多个 stash 怎么管理才不混乱
靠命名 + 列表查看。Git 默认给每个 stash 起名类似 WIP on main: 1a2b3c4 fix login bug，但这种自动生成的名字在 stash 多了以后根本分不清哪个是重构 CSS、哪个是临时注释掉的 API 调用。
创建时就加描述：
git stash push -m "css: move button hover to utility class"
然后用 git stash list 清晰看到带语义的记录：
stash@{0}: On main: css: move button hover to utility class
stash@{1}: On feature/auth: api: disable 2fa check for testing
- stash 名称不支持空格开头或特殊符号，别写
"[WIP]..."或"fix: ✅"，容易解析失败 - 删错 stash？
git stash drop stash@{1}比git stash clear安全得多 - 想把某个 stash 变成分支来深入开发？
git stash branch new-feature stash@{1}，Git 会自动创建分支并应用该 stash
git stash 在 rebase 过程中能用吗
能，但要格外小心顺序。rebase 本质是一系列 cherry-pick，而 git stash 操作依赖当前工作目录和暂存区状态。如果在 rebase 中途（比如停在某个 commit 修改冲突时）执行 git stash，它保存的是当前 rebase 中间态的变更，不是原始分支上的干净快照。
更常见也更安全的做法是：rebase 前先把本地修改 stash 掉；rebase 完成后再 apply 回来。
- rebase 已开始，又突然要切走？先
git rebase --abort或--continue把当前 rebase 收尾，再 stash - 不小心在 rebase 中 stash 了？用
git stash show -p stash@{0} | git apply -R可以反向撤销（慎用） - rebase + stash 组合最易出问题的点：同一个文件在 stash 里改了 A 行，在 rebase 的某个 commit 里也改了 A 行——apply 时大概率冲突，且上下文难追溯
真正麻烦的不是命令会不会用，而是 stash 记录和当前 HEAD 的语义距离。越晚查看、越不加描述、越频繁跨分支使用，就越容易对着一个 WIP on develop 发呆三分钟。
