“modified”表示文件在工作目录中被修改但未暂存；“AM”是简洁模式下的双字母状态码，A表示已执行git add暂存，M表示暂存后又在工作目录中被修改，即暂存区与工作目录内容不一致。
git status 输出里“modified”和“AM”分别代表什么
“modified”表示文件在工作目录中被改动过，但还没执行 git add，属于「未暂存的修改」；而 AM 是 git status -s 简洁模式下的双字母状态码，其中 A 表示该文件刚被 git add 进暂存区，M 表示随后又被改过——即「已暂存但工作目录有新改动」。
常见混淆点：看到 AM 就以为文件已干净，其实它比单纯 M 更危险，因为 git commit 只会提交暂存区版本（第一次 add 时的内容），你后来改的那部分不会进提交。
- 用
git status -s时，??是未跟踪文件，M是仅工作目录修改，A是仅暂存、未改，AM是暂存后又改 - 想确认某次提交到底包含哪些变更，别只看
git status，要配合git diff --cached看暂存区快照 - 误操作后想还原到暂存区状态，用
git restore --staged <file>，不是git checkout（后者已弃用）
为什么 git status 不显示远程分支差异，或提示“up to date”却实际落后
git status 默认不拉取远程最新信息，它只对比本地 HEAD 和本地远程跟踪分支（如 origin/main）的记录。如果很久没运行 git fetch，本地的 origin/main 引用就 stale 了，导致 “up to date” 是假象。
真正判断是否落后，得先同步元数据：
- 运行
git fetch更新所有远程分支引用（不合并、不改工作目录） - 再执行
git status -b，就会显示类似your branch is behind 'origin/main' by 3 commits - 如果只想查特定远程，用
git fetch origin main，更轻量 - 别依赖 GUI 工具或 IDE 内置的 Git 面板，它们可能缓存旧状态，终端里跑一遍
git status -b最可靠
如何快速定位某个文件在 git status 中的状态
直接对单个文件或路径执行 git status，Git 会过滤输出，只显示与该路径相关的状态行，比扫全量输出高效得多。
比如项目根目录下改了 src/utils.js，但不确定它是否被忽略或暂存，可以：
-
git status src/utils.js—— 显示它当前是modified、deleted还是ignored -
git status --ignored src/—— 加--ignored参数，能同时看到被.gitignore排除的文件（默认不显示） - 路径支持通配符，
git status "docs/*.md"要加引号，避免 shell 展开 - 注意：如果文件根本不在 Git 管理范围内（既未跟踪也未忽略），
git status默认不提它，除非加--untracked-files=all
git status -s 输出里颜色失效或符号乱码怎么办
终端里 git status -s 的颜色和符号（如 →、✔️）依赖终端编码、字体支持和 Git 配置。乱码通常不是 Git 本身问题，而是环境没对齐。
优先检查三项：
- 确认终端使用 UTF-8 编码：
echo $LANG应含UTF-8，否则设export LANG=en_US.UTF-8 - Git 颜色开关是否打开：
git config --get-colorbool color.status返回true才生效；若为false，运行git config --global color.status auto - 某些老旧终端（如 Windows CMD）不支持 Unicode 符号，换成
git status -s --no-optional-locks或改用 WSL / Windows Terminal - 别用
git status --porcelain来人工解析颜色——它是给脚本用的机器可读格式，无颜色、无空格、严格两列，适合awk或 CI 解析
最常被忽略的是 fetch 同步这一步：很多人每天 git status 看着“up to date”，却不知道自己漏掉了上游关键修复，直到 git pull 报冲突才反应过来。记住，git status 是本地快照，不是实时联网诊断工具。
