Git文件状态标志详解：U、M、D、A在编辑器中究竟代表什么？

如果你用的是VS Code这类带Git集成的编辑器，应该早就注意到一个现象：文件列表里某些文件名的末尾会挂着小字母——有时是U，有时是M，偶尔是D，颜色还各不相同。我当年第一次看到时，第一反应是“插件是不是装坏了”，后来才发现，这其实是Git在借编辑器的界面跟我汇报每个文件当前的状态。

这篇文章就把U、M、D、A这些标志一次性讲透。我会从Git区域的底层机制讲起，再到常见编辑器里的不同展示方式，最后用几个真实场景演示“看到U/M/D之后到底该怎么操作”。不管你是刚接触Git的新手，还是用了很久但一直靠“肌肉记忆”点按钮的“差不多先生”，这篇文章都能帮你把这块拼图补上。

1. 先搞清楚一件事：U和M不是编辑器自己发明的

1.1 从“文件后面多个字母”说起

先还原一下第一次看到这些字母的典型场景：你打开编辑器，准备改代码，突然发现文件名后面多了个M，但你回想一下，自己好像也没动过这个文件。再往下看，某个新建的文件后面多了个U，另一个被删掉的文件后面多了个D。

这些字母在VS Code、Sublime、Atom等编辑器里都可能出现，它们不是编辑器随手生成的装饰品，而是Git通过编辑器这个“翻译器”向你展示的文件状态。说得直白点：Git在你的项目目录里埋了一双眼睛，监视着每个文件跟“上一次提交时”相比发生了什么变化，而编辑器只是把这双眼睛看到的结果，用U、M、D这样的简写符号显示在文件后面。

1.2 Git其实是个“记账员”

要理解这些字母，先得理解Git的底层工作逻辑。Git内部维持着三个主要区域：工作区、暂存区（也叫索引）和本地仓库。

可以拿日常生活打比方：工作区是你的办公桌，你可以在上面随便摊开文件、修改、涂鸦。暂存区是一个“待提交的透明文件夹”，你把想要提交的文件先放进去，相当于告诉Git“这几个文件我准备写进历史记录”。本地仓库则是保险柜，所有提交成功的内容都会固化成一份带版本号的档案，存进保险柜。

一个文件从生到死的完整流程大概是这样的：

• 刚创建时，它只存在于工作区，Git完全不认识它，于是标记为“未跟踪”。
• 执行git add之后，文件被复制进暂存区，状态变成“已暂存的新增”。
• 执行git commit之后，暂存区的内容固化进仓库，文件状态变成“已跟踪且无改动”，编辑器里的字母也就消失了。
• 之后你再次修改这个文件，工作区和仓库之间产生差异，Git又会标记为“已修改”。

理解了这条循环，再看编辑器里的字母就会发现：每一个符号背后，都是一条“某个区域与另一个区域不一致”的记录。

1.3 状态速查表

下图是常见状态标志的快速对照，可以先收藏备用：

注意：这张表里的U是“编辑器世界的U”，代表未跟踪，跟终端命令git status --short里的U含义不一样。这一点非常重要，后面我会单独用一个小节讲透。

2. 读懂Git状态符号：一列字符背后，是“工作区”和“暂存区”两套账

2.1 git status --short 两列的秘密

很多人只看编辑器里的字母，却不知道这些字母其实源自git status --short这个命令的输出。终端里这个命令会显示类似??、M、M、MM的两列字符，这其实是Git自身输出的“编码”。

两列的含义是：左边一列代表“暂存区状态”，右边一列代表“工作区状态”。可以想象成两本账本，左边记录“你准备提交什么变更”，右边记录“你现在实际上改了什么”。

举个例子：

• ??：两列都是问号，表示这个文件既没被跟踪，也没进暂存区，纯属野生文件。
• M：左边是空格，右边是M，表示暂存区里没有这个文件的变更，但工作区里它被改过了，属于“改完还没git add”。
• M：左边是M，右边是空格，表示这个文件已经git add过了，暂存区里有它的变更，但工作区在add之后没再继续改，属于“已暂存还没提交”。
• MM：左边是M，右边也是M，表示这个文件太“折腾”了——你add完一次之后又改了一版，所以暂存区里有一个旧版本的变更，工作区里还有一个新版本的变更。

这四组符号是新手最容易混淆的地方，我见过太多人对着MM一脸问号，其实它只是在告诉你：“你现在有两层变化，一层在篮子里，一层在桌子上。”

2.2 主状态符号逐个拆解

下面逐个拆解常见状态符号及其触发场景。

U / ?? —— 未跟踪

新建一个文件但没执行git add时，就会进入这个状态。在VS Code的源代码管理面板里，它会直接显示一个大大的U。它的本质是：这个文件对于Git来说还是个陌生人，Git虽然知道它的存在，但不会主动跟踪它的变化。

触发场景：在项目根目录新建了config.js、.env、notes.txt等文件，但还没告诉Git“我要管理它”。这也就是为什么很多项目里会出现一大堆.tmp、node_modules之类的U文件——它们没有加入.gitignore，又没被add，所以一直挂在未跟踪列表里。

M —— 已修改

一个已经被Git跟踪的文件，只要工作区内容和暂存区/仓库不一致，就会亮起M。最常见的触发方式就是：打开某个已经提交过的文件，往里加了几行代码，保存，编辑器立刻给你挂上M。

M这个字母的覆盖范围很怪：它既可能表示“改了还没add”，也可能表示“add完又改了”，甚至可能是“你只是改了个换行符也能触发”。判断具体属于哪种，看终端里空格落在左列还是右列。

A —— 已暂存的新增

一个新建文件执行了git add之后，它从U变成了A。A告诉你：这个文件已经进入暂存区，是“准备提交”的状态，但还没真正写进历史。此时如果直接commit，这个文件就会正式进入版本库。

D —— 已删除

文件在某个时间点被git rm或者在文件系统里被删掉，Git发现它“曾经跟踪过，现在不见了”，就标记为D。D同样分未暂存和已暂存两种：如果你只是手动在文件管理器里删了文件，Git会显示D；如果你用git rm file删除，Git会直接把删除操作放进暂存区，显示D。

R —— 已重命名

当文件被移动并修改，Git会通过相似度判断是否算重命名。这个状态在编辑器里不太常见，但在JetBrains系列和GitKraken里偶尔出现，含义是“这个文件改名了”。

2.3 同叫U，含义却完全不同：untracked 与 unmerged 的坑

现在说回到文章开头埋下的坑：同样是字母U，在不同语境下，含义完全不同。

在编辑器里，U代表“Untracked”，也就是“未跟踪”。但在git status --short的标准输出里，U代表“Unmerged”，也就是“合并冲突未解决”。比如UU、AU、UD、UA、DU、AA、DD这些组合，都是在描述文件在合并过程中处于冲突状态，而不是“未跟踪”。

这个坑我踩过不止一次。有一次我在终端里跑git status，看到某个文件前面挂着U，第一反应是“这文件不是早add过了吗，怎么还是U”，然后库库一顿操作想把文件add一下，结果Git直接拒绝，提示文件有未解决的冲突。后来才反应过来，这里的U并不是编辑器里那种“新文件未跟踪”的意思。

区分方法很简单：先看你是通过什么途径看到的U。如果是编辑器文件列表后面的字母，大概率是未跟踪；如果是终端git status --short输出里的U，基本可以断定是冲突。要百分之百确认，可以在终端跑两条命令：

# 列出所有未跟踪文件 git ls-files --others --exclude-standard # 列出所有未合并（冲突）文件 git diff --name-only --diff-filter=U

这两条命令是我日常用得最频繁的判别利器，建议收藏。

3. 在VS Code、JetBrains和GitHub Desktop里，这些标志到底长什么样

3.1 VS Code：最直观的字母徽章

VS Code是目前最常被问到这类问题的编辑器，因为它把Git状态直接做成了文件列表里的字母徽章。默认情况下，当文件处于未跟踪状态时，文件名右侧会出现字母U；已修改但未暂存时，出现M；已暂存时，出现A或M（取决于新增还是修改）；删除时出现D。

同时，左侧活动栏里的“源代码管理”图标（一个分叉小树苗）会显示一个数字角标，数字代表当前工作区里有几处变更。点开之后，会看到下面几个分组：

• 更改：未暂存的变更，对应git status里的“Changes not staged for commit”。
• 暂存的更改：已经add但还没commit的变更，对应“Changes to be committed”。

这个面板里有一个非常实用的细节：每个文件右侧有一个“+”号，点击它就能完成git add操作，文件会从“更改”分组移动到“暂存的更改”分组。解决完冲突后，左上角的输入框里填写提交信息，再点“提交”按钮，就等于执行了一次git commit。

VS Code还有一个被低估的功能：在“源代码管理”面板里选中某个修改过的文件，右键选择“打开更改”，会弹出一个对比视图，左边是HEAD版本，右边是当前工作区版本，你一眼就能看到自己具体改了哪些行。这个功能在处理M状态时比终端里的git diff更直观。

3.2 JetBrains系：用颜色代替字母

如果你用的是IDEA、PyCharm、GoLand这类JetBrains系编辑器，会发现它们不太喜欢用字母，而是用颜色和图标来标记Git状态。

在Project树里，未跟踪的新文件会被标成红色，已跟踪但修改过的文件是蓝色的，已暂存的修改是绿色的，删除的文件会带删除线，重命名文件会有小图标提示。在底部“Version Control”工具窗口的“Changes”面板中，列表也会按颜色区分状态，同时还支持一个非常香的功能：右键某个文件，选择“Show Diff”，可以跟任意历史版本对比。

JetBrains系和VS Code的区别很有意思：VS Code把“未跟踪”直接写成了字母U，一眼就能看到；JetBrains系只给未跟踪文件标红，不写字母，很多人对着红色文件也摸不着头脑。所以如果你在JetBrains系里看到红色文件，它对应的就是VS Code里的U状态。

3.3 其他常见客户端与编辑器的表现

除了VS Code和JetBrains系，还有一些常见客户端也有自己的展示方式，整理成表方便对照：

这些工具底层调用的都是同一套Git状态机制，只是换了一层“皮肤”。理解了原理，换哪个工具都能快速适应。

4. 面对U、M、D不慌：四个场景的完整排查链路

4.1 场景一：新增文件出现U，怎么提交第一次

假设你在项目里新建了一个README.md，编辑器文件列表里立刻多了一个U。此时这个文件只是存在于工作区，Git没在管理它。目标是让它进入Git管理，并提交到本地仓库。

操作用VS Code的话，有两条路线。

路线一（纯界面操作）：打开“源代码管理”面板，看到“更改”分组里有一个“U README.md”条目。点右侧的+号，文件会从“更改”移动到“暂存的更改”，U变成A。接着在面板上方的输入框里写提交信息，比如docs: add readme，然后点提交按钮。此时文件状态消失，代表它已经正式进入版本历史。

路线二（终端操作）：

# 用git status确认当前状态，会看到?? README.md git status # 将README.md加入暂存区 git add README.md # 查看暂存区是否生效，应该看到A README.md git status # 提交 git commit -m "docs: add readme"

这里有一个新手很容易犯的错：直接git commit -am "..."。-a参数只会自动暂存“已经被跟踪”的修改文件，对新增的U文件无效。想靠-am一次性提交新建文件，是不行的，必须先git add把它变成A。

4.2 场景二：修改文件出现M，想看改动、想回退

某一天你打开src/index.js，文件名后面挂着M。这时候不要急着去网上搜“git M是什么意思”，先在终端里跑一下git status，它会用更详细的文字告诉你完整故事：

On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: src/index.js

接下来分两种需求。

需求一：我想看看改了哪里。终端里执行：

git diff src/index.js

输出的内容会以+和-的形式展示每一行改动。如果嫌终端输出太长，VS Code里的“打开更改”视图更友好，左右对比，一眼能看到加了什么、删了什么。

需求二：我改坏了，想放弃这次修改，恢复到上次提交时的状态。终端里执行：

# 新版，推荐 git restore src/index.js # 老版命令，2.23之前的Git用这个 git checkout -- src/index.js

如果只想恢复某个文件的某几行，而不是全部丢弃，可以用交互式暂存：

git add -p src/index.js

这个命令会逐段问你“是否暂存这段修改”，你会看到类似Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?的提示。输入y暂存这一段，n跳过这一段。这样就能实现“部分保留、部分丢弃”。

4.3 场景三：删除文件出现D，如何恢复或确认删除

文件被删，Git立刻在编辑器里标出一个D。很多人看到D就慌了，但其实删除也是一种变更，处理方式很灵活。

如果只是误删，想恢复文件，分两种情况：

• 删除还没暂存，也就是git status显示D file.txt：直接用git restore file.txt就能从暂存区恢复文件。
• 删除已经暂存，也就是执行过git rm file.txt或git add file.txt后文件消失：用一条命令搞定：

git restore --staged --worktree file.txt

这条命令的意思是：同时从暂存区和工作区恢复file.txt。如果Git版本较老，可以改用：

git checkout HEAD -- file.txt

两条命令都能把误删的文件恢复成上一次提交的状态。

如果确认这个文件确实不要了，那就别恢复，让它保持D状态，然后：

git rm file.txt git commit -m "remove file.txt"

这样Git历史里就会正式记录“这个文件已经被删除”，以后想找回来还能通过历史版本找回。

4.4 场景四：合并冲突出现C或UU，怎么处理

合并冲突是状态标志里最让人头疼的一种。在VS Code里，冲突文件会显示C；在终端git status --short里，会显示UU、AA、DD这类组合。无论哪种，背后的原因都是“两个分支改动了同一个文件的同一块区域，Git不知道该听谁的”。

举个例子：你在dev分支改了index.js的第一行，然后main分支也改了index.js的第一行。merge的时候Git就卡住了，把两个版本都留下，让你来拍板。

打开冲突文件，你会看到类似下面的内容：

<<<<<<< HEAD const name = "main"; ======= const name = "dev"; >>>>>>> dev

<<<<<<< HEAD和=======之间是当前分支（HEAD）的版本；=======和>>>>>>> dev之间是dev分支的版本。此时你有四种选择：

• 保留当前分支的版本：删掉<<<<<<< HEAD、=======、>>>>>>> dev三行，只保留const name = "main";。
• 保留dev分支的版本：只保留const name = "dev";。
• 两个版本都要：两行都保留。
• 手动改成全新内容：比如写成const name = "both";。

处理完后，保存文件，然后执行：

git add index.js git commit -m "merge: 解决index.js冲突"

这里有一个重要提醒：不要直接删除冲突标记后不做add就commit。Git要求所有冲突都要被标记为“已解决”，也就是至少要把文件加入暂存区，才会允许生成合并提交。彻底放弃的话，也可以直接git merge --abort取消这次合并。

5. 把状态标志用成“工作流仪表盘”：实用习惯与进阶技巧

5.1 看到标志先别慌，先在终端跑一次git status

编辑器里的小字母只是“缩写”，真正完整的解释永远藏在git status的输出里。我见过太多人对着编辑器里的U抓耳挠腮，既不敢提交也不敢删，其实只要打开集成终端跑一下git status，Git会明确告诉你下一步可以做什么。

例如未暂存的修改，Git会提示“use git add to update what will be committed”；未跟踪的新文件，Git会提示“use git add to track”。学会看这些提示，比记住所有命令参数重要得多。

5.2 别让无效文件刷屏：配置.gitignore

如果你发现新建了一堆临时文件后，U标志刷满了整个文件列表，那就是时候配置.gitignore了。它的作用是在Git层面忽略某些文件或目录，让它们永远不会被跟踪，也就不会再显示U。

举一个常见的Node.js项目例子：

# 依赖目录 node_modules/ # 构建产物 dist/ dll/ lib/ # 日志 *.log npm-debug.log* # 系统文件 .DS_Store Thumbs.db # 环境变量（通常包含密钥，不入库） .env .env.local

配置好之后，编辑器里的U会自动消失，因为Git已经“无视”这些文件了。如果没有这个文件，新人克隆项目后跑一次构建，立刻会出现上百个U标志，看谁都像要提交的东西，体验会很糟糕。

5.3 我给自己的几个“硬规矩”

调节状态标志这么多年，我慢慢形成了几个习惯，分享出来供参考。

第一个规矩：开工前先看一眼“源代码管理”面板。不是让你每次都提交，而是确认自己“是从一个干净的状态出发的”。如果面板里提前带着脏东西，后面改起来容易越改越乱，最后连哪个改动是自己的都分不清。

第二个规矩：小步提交。完成一个功能点、修完一个bug、调完一轮样式，就commit一次，提交信息写清楚。这样做有个好处：Git状态仪表盘上的数据永远是清晰的，M和U不会积压太久。

第三个规矩：改完代码先看diff再提交。不管是在编辑器里“打开更改”，还是在终端跑git diff，都要养成确认差异的习惯。很多人提交前不检查，结果把自己误加的调试语句、日志输出全都提交进去了，之后排查问题还要靠git log -p回翻。

第四个规矩：遇到看不懂的标志先查git status原文，别急着点编辑器里的按钮。编辑器把复杂的Git命令压缩成了一个字母一个按钮，给人感觉操作很简单，但也把很多底层信息藏了起来。只有回到终端去看原始输出，你才能真正明白Git在告诉你什么。

5.4 关于“编辑器集成的边界”一点提醒

最后提醒一点：编辑器里的Git状态展示依赖两个前提——第一，当前打开的文件夹是一个Git仓库；第二，编辑器自带的Git集成功能正常启用（VS Code里是git.enabled配置项，通常默认为true）。

如果你打开了某个项目，但发现文件后面完全没有任何状态标志，先检查是不是忘了执行git init，或者这个文件夹根本不在仓库根目录内。还有一种情况是公司安全策略默认禁止了编辑器的Git集成，那就要靠命令行或外部Git客户端来补位了。

我现在已经习惯了看到M就条件反射地想“我又动了什么”，看到U就琢磨“新文件该不该入版本库”。这套符号体系一旦用起来，就像一个仪表盘，让你在写代码的每一分钟都知道自己的工作区处于什么位置。把它当成朋友，而不是麻烦，你的版本管理体验会顺畅不少。