U表示未合并（存在合并冲突），M表示已修改未暂存，A表示已暂存未提交；它们源自git status -s输出，仅反映工作区与暂存区差异，?和D分别代表未跟踪新文件和已删除未暂存文件。
Git 状态标记 U、M、A 在 VSCode 源代码管理里分别对应什么操作
这些字母是 Git 工作区状态的简写，直接来自 git status -s 的输出格式，VSCode 只是原样展示。不是 VSCode 自创的符号，也不依赖插件或设置。
关键点：它们只反映「当前工作目录下文件相对于暂存区（index）的状态」，和远程仓库无关；且大小写敏感——M 和 m 含义完全不同。
-
U：Unmerged，表示该文件存在合并冲突，Git 无法自动解决，需要手动编辑。常见于git merge或git pull后未处理冲突文件 -
M：Modified，文件已被修改但尚未git add，处于“已修改未暂存”状态 -
A：Added，文件已通过git add加入暂存区，但还没提交（即“已暂存未提交”）
为什么有时候看不到 U/M/A，或者显示成 ? 或 D
VSCode 的源代码管理视图默认只显示「已跟踪（tracked）文件」的变化。未被 Git 跟踪的新文件显示为 ?，已删除但未 git rm 的文件显示为 D。
容易踩的坑是误以为 ? 是“未知状态”，其实它只是 Git 还没管过这个文件；而 U 出现时，VSCode 通常还会在文件名旁加个红色感叹号，但不会高亮冲突行——得靠打开文件看
- 想让新文件也显示为
A？先执行git add，别只在 VSCode 点「+」图标（有时会失败，尤其路径含空格或中文） -
U状态下右键「放弃更改」会直接丢弃所有本地修改，包括冲突部分——不是回退到合并前，而是强制用远端版本覆盖，慎点 - 如果某个修改过的文件一直显示
M，但git status里没有它，可能是 .gitignore 里误写了规则，或文件权限变更触发了 Git 的 chmod 记录（Linux/macOS 下较常见）
VSCode 里点击这些标记实际触发什么 Git 命令
VSCode 的图标按钮本质是封装了基础 Git 命令，但不完全等价于你在终端敲的命令，尤其涉及暂存逻辑时。
- 点击
M文件旁的「+」：执行git add，状态变为A；但如果该文件之前是U，这一步会失败并报错「Unable to stage: unable to index file」 - 点击
A文件旁的「×」：执行git restore --staged（Git 2.23+），状态变回M；旧版 Git 会 fallback 到git reset HEAD - 点击
U文件旁的「×」：执行git checkout --ours或--theirs，取决于你选哪个分支保留——但 VSCode 不会弹窗让你选，它默认用当前分支（HEAD）版本，相当于丢弃对方改动
哪些场景下这些标记会“失灵”或显示异常
标记依赖 Git CLI 的实时输出，VSCode 只轮询或监听 fs 事件更新。当 Git 状态和 VSCode 视图不同步时，最直接的表现就是标记卡住不动。
- 在终端执行了
git commit或git stash后，VSCode 源代码管理视图可能仍显示旧的A或M，需手动点击右上角刷新按钮（或按 Ctrl+Shift+P →「Git: Refresh」） - 使用 WSL2 + Windows 版 VSCode 时，若文件在 /mnt/c/ 下，Git 可能因文件系统差异漏报
M（比如仅修改了换行符） - 开启 Git 的
core.autocrlf但项目跨平台协作时，M可能频繁出现又消失——这不是 bug，是 Git 在自动转换 CRLF/LF，建议统一设为core.autocrlf=input（macOS/Linux）或true（Windows）
真正麻烦的是 U 和子模块嵌套冲突：VSCode 不会展开子模块内部的 U，只会把它当普通已修改文件，但实际要进子模块目录单独 resolve。这点很容易漏掉，直到 push 失败才意识到。
