VSCode的Git stash功能默认只处理已跟踪文件，不包含新建未add文件；需精细控制（如仅stash staged、含untracked）必须用终端执行git stash push命令。
VSCode 的 Git stash 功能能用，但默认只处理已跟踪文件，不 stash 新建未 add 的文件；想精细控制（比如只 stash staged 部分、带 untracked 文件、跳过暂存区），必须切终端手动执行 git stash push 命令。
怎么触发 stash：三个入口，效果有差异
VSCode 提供三种调用 stash 的方式，但底层行为不完全一致：
- 命令面板输入
Git: Stash→ 执行git stash push -m "VS Code stash"，仅 stash 已跟踪文件的全部修改（含未暂存 + 已暂存） - 源代码管理视图（
Ctrl+Shift+G）→ 点右上角⋯→Stash Changes→ 同样执行默认 push，但会弹出可编辑的描述框 - 右键某个已修改文件 →
Stash Changes→ 行为同上，不是只 stash 该文件，而是 stash 全局所有修改
注意：这三个入口都不支持 -S（只 stash staged）、--include-untracked 或 -u（含 untracked）等参数，需要就得开终端。
为什么新文件没被 stash？如何让它进去
VSCode 默认忽略未跟踪（untracked）文件，哪怕你刚新建了一个 utils.js 并写了几十行，Git: Stash 也不会把它收进去——这是 Git 本身的设计，VSCode 只是忠实地封装了默认行为。
- 临时解决：在终端运行
git stash push -u -m "with untracked"，-u参数强制包含未跟踪文件 - 长期设置：VSCode 设置中搜索
git.untrackedChanges，改为all，之后图形化 stash 就会自动带上新建文件（但依然不支持-S或冲突时精细跳过） - 警告：如果新建文件里有敏感配置或本地密钥，
-u会一并 stash，切记检查
stash 后怎么恢复？pop 和 apply 别混用
恢复操作有两个常用命令，行为关键不同：
-
Git: Pop Stash→ 执行git stash pop，应用最近一条 stash 并从栈中删除它。如果应用后产生冲突，stash 不会自动删掉，但工作区已脏，需手动解决再git add/git stash drop -
Git: Apply Stash→ 执行git stash apply，只应用不删除，适合“先看看改得对不对”，确认无误再手动git stash drop stash@{0} - 查看 stash 列表用
Git: Show All Stashes，列表格式是stash@{0}: On main: xxx，数字越小越新；按Delete键可删选中项
别在合并进行中或存在冲突时点 stash 按钮——VSCode 会直接禁用，这不是 bug，是保护机制，强行绕过可能破坏索引状态。
哪些场景必须切终端？
图形界面省事，但遇到这几类需求，VSCode 内置 stash 就不够用了：
- 只想 stash 已暂存（staged）部分，保留未暂存修改继续调试 → 必须
git stash push -S - 要 stash 一部分修改、保留另一部分（比如只 stash bugfix，留着实验性 feature）→ 得先
git add -p精确暂存，再git stash push -S - stash 后想看内容差异 → VSCode 不提供预览，终端跑
git stash show -p stash@{0}最直接 - 批量 drop 多个旧 stash → 图形界面只能逐个删，终端用
git stash clear或git stash drop stash@{1} stash@{2}
真正容易被忽略的是：stash 不是备份，它依赖当前分支的 HEAD 状态。如果在 stash 之后又做了提交、变基或切换到另一个 diverged 分支再 pop，很可能出现意料外的冲突或内容错位——别把它当 git commit 的轻量替代品。
