VSCode提示“在签出前请清理存储库工作树”需用git stash暂存未提交更改后再操作；stash默认只处理已跟踪文件，未跟踪文件须终端执行git stash push -u，pop失败常因冲突静默导致。
VSCode 里“在签出前请清理存储库工作树”怎么快速解决
这是 Git 拒绝操作的明确提示，本质是工作区有未提交变更（git status 显示 modified/untracked 文件），而你正试图执行会覆盖这些文件的操作（如 git checkout、git pull、切换分支）。VSCode 不会自动帮你丢弃或暂存——它只报错，不决策。
最稳妥的路径不是硬删，而是用 git stash 把当前修改“打包存档”，让工作区变干净，等拉取/切换完成后再恢复。快捷键本身没变，但触发方式依赖上下文：
- 确保左侧活动栏已点击「源代码管理」图标（分支图标），且右下角显示当前分支名（如
main） - 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS）打开命令面板 - 输入
Git: Stash Changes并回车——若工作区只有未暂存修改，会直接执行；若已有git add过的文件，会弹窗让你选是否包含暂存区内容
为什么 git stash pop 恢复后还有红色感叹号
VSCode 左下角无报错但文件仍标红，说明 Git 认为该文件“已修改”，但 VSCode 的状态缓存或文件监视器没及时刷新。常见于 git stash pop 后发生冲突又手动编辑过，或恢复时部分行被合并工具标记为冲突残留（比如 <<<<<< HEAD 这类标记没清干净）。
Git Repo Reader
下载
辅助阅读和快速理解 GitHub/Git 项目结构与核心价值的结构化方法论。 当用户请求"分析这个 GitHub 项目"、"帮我读一下这个 repo"、"了解这个项目是做什么的"、 "怎么用这个项目"、"怎么跑这个项目"、"这个项目用了哪些技术"，或任何涉及 GitHub/Git 仓库阅读、理解、技术评估、快速上...
不要直接删文件。先检查：
- 在终端运行
git status，看是否真有 unmerged 状态——如果有，说明冲突没真正解决 - 打开对应文件（如
index.vue），搜索<<<<<<、=======、>>>>>>，删掉整段冲突标记及中间冗余代码 - 保存文件后，在源代码管理视图中右键该文件 →
Stage Changes，再点右上角 √ 提交 - 若仍标红，重启 VSCode 或执行
git update-index --refresh强制刷新索引
git stash apply 和 git stash pop 在 VSCode 里怎么选
VSCode 命令面板里有 Git: Apply Stash 和 Git: Pop Stash 两个选项，区别不在“是否删除”，而在失败时的安全性：
-
Git: Apply Stash对应git stash apply：恢复内容但保留 stash 记录。即使恢复过程因冲突中断，stash 还在栈里，能重试 -
Git: Pop Stash对应git stash pop：恢复 + 删除记录。一旦冲突导致失败，stash 就丢了，原始修改也回不来 - 日常建议始终先用
Apply，确认无误后再手动git stash drop stash@{0}删除 - 如果必须用
Pop，确保工作区当前是干净的（git status无输出），否则冲突失败会导致双失
VSCode 暂存区恢复时容易忽略的路径细节
VSCode 的 stash 恢复入口藏得深，且不支持鼠标单击直接应用——必须通过命令面板。更关键的是，它默认只恢复最近一次 stash（stash@{0}），不会列出全部供选。如果你执行过多次 git stash，想恢复某次特定记录：
- 先在终端运行
git stash list，记下目标 stash 的编号（如stash@{2}） - 在 VSCode 终端里手动执行
git stash apply stash@{2}，而非依赖图形界面 - VSCode 的「Stashes」面板只在源代码管理视图展开后才可见，但它不支持点击某条目后输入编号——它只提供「Apply」和「Pop」按钮，且默认作用于最新一条
- 长期来看，给每次 stash 加描述（
git stash push -m "wip: 表单校验逻辑"）比依赖编号更可靠
