git status -s输出为两列字符，左列表示暂存区状态、右列表示工作区状态；如MM file.txt表示该文件在暂存区和工作区均被修改，?? new.log表示未跟踪的新文件。
git status -s 输出字段含义怎么看
直接用 git status -s（或 git status --short）就能拿到两列字符摘要，每行代表一个文件的状态。左边是暂存区（staging）状态，右边是工作区（working tree）状态，空格表示“未变化”。比如：MM file.txt 表示该文件在暂存区和工作区都被修改过；?? new.log 表示未跟踪的新文件。
常见状态码组合及对应操作建议
状态码只有两个字符，但组合起来有十几种，实际高频的就几个：
-
M：工作区修改未暂存 → 用git add加入暂存区 -
MM：已暂存修改 + 工作区又改了 → 暂存的是旧版，当前是新版，常出现在编辑后忘记git add -
A：文件已git add但还没 commit → 下次 commit 会包含它 -
D：工作区删了文件，但没git rm→ 暂存区还记着它，下次 commit 会报错“deleted in working directory” -
??：全新文件，git 完全不知道 → 需手动git add或配置.gitignore
为什么 git status -s 不显示中文路径或特殊字符
默认情况下，git status -s 对非 ASCII 路径会显示八进制转义（如 \344\272\214\346\226\207\344\273\266.txt），这不是 bug，而是 Git 内部对路径的原始字节处理方式。解决方法有两个：
- 加
--no-abbrev参数（Git 2.30+）可强制显示原生 UTF-8 路径 - 设置
core.quotePath = false（git config --global core.quotePath false），之后所有status输出都不转义
注意：后者会影响所有 Git 命令的路径显示，包括 git log --oneline，某些 CI 环境可能依赖默认转义行为。
想快速统计修改类型数量，别用肉眼数
靠扫屏数 M、D、?? 很容易漏，尤其当文件多时。可以用管道配合 awk 或 grep -c：
git status -s | awk '{print $1}' | sort | uniq -c
输出类似：
3 M
1 ??
这比反复敲 git status -s | grep "^M " 更可靠。如果只关心暂存区变动，加 ^ 锚定首字符：git status -s | grep "^[A-Z]" | wc -l —— 注意这里匹配的是左边非空字符，不包括 ?? 和空格开头的已提交文件。
真正容易被忽略的是重命名检测：当 Git 认为某次修改实质是重命名（比如 git mv a.txt b.txt），git status -s 会显示 R 开头（如 R a.txt -> b.txt），但默认阈值是 50% 内容相似度，如果你手动改名又微调内容，它可能拆成 D + ??，这时候就得结合 git diff --name-status 看更准确的变更语义。
