“nothing to commit”是因为文件未被Git跟踪，而非Git异常；新文件默认为untracked状态，需git add加入跟踪，且需检查.gitignore是否屏蔽了该路径。
git status 显示“nothing to commit”但文件明明改了
这是新手最常懵的点：改完代码，git status 却说没变化。根本原因不是 Git 坏了，而是文件压根没被 Git 跟踪过。
Git 只关心三类文件：已跟踪（tracked）、暂存（staged）、未跟踪（untracked）。刚新建的文件默认是 untracked，git status 会列出它们，但不会标为“modified”——只有已跟踪文件改动后才会显示 modified。
- 用
git status -u（或git status --untracked-files=all）确保未跟踪文件被显示出来 - 如果文件在列表里但状态是
Untracked files:下面，说明它还没进 Git 管理，得先git add <file> - 检查 .gitignore 是否意外屏蔽了该文件路径，比如写了
src/*.js却忘了加!白名单
git status 输出里出现红色和绿色文字，分别代表什么
颜色本身不重要，关键是对应的状态语义。默认配色下，红色 = 工作区改动未暂存，绿色 = 已暂存待提交。
比如你改了一个已跟踪的 index.js：
- 只改了没
git add→ 出现在Changes not staged for commit下，通常是红色 -
git add index.js后 → 移到Changes to be committed下，通常是绿色 - 再改一次 → 同时出现在两个区域：绿色行（上次暂存的内容），红色行（新改的部分）
注意：颜色可被关闭（git config --global color.ui false），别依赖颜色判断，看文字分区更可靠。
为什么 git status 很慢，尤其在大仓库里
慢通常是因为 Git 在扫描工作目录所有文件做比对，尤其是启用了某些钩子或集成工具时。
- 检查是否开了
fsmonitor：运行git config core.fsmonitor，若为空或false，可尝试启用（Windows/macOS 支持较好）：git config core.fsmonitor true - 排除大型构建产物目录：把
node_modules/、dist/、build/加进.gitignore，否则每次git status都要遍历成千上万个文件 - 禁用 Windows 的长路径监控（仅限 Windows）：
git config core.longpaths false，有时能缓解卡顿
git status -s 和 git status --short 输出看不懂
git status -s 是精简模式，两字符编码代替完整描述，适合脚本或快速扫一眼，但初学容易混淆。
常见组合含义（左=暂存区，右=工作区）：
-
MM：文件已暂存，又改了一次（如先add再改） -
A?：新增文件，未add（A表示已暂存新增，??才是纯未跟踪） -
DD：文件被删了两次？其实是误操作：第一次rm后没add，第二次又rm—— 正确流程是git rm <file>或git add -u
记不住就直接用 git status 不带参数，语义清晰；需要机器解析时再切 -s，别硬背缩写。
真正卡住人的往往不是命令本身，而是没意识到 Git 的状态是分层的：工作区、暂存区、HEAD 各自独立。一个文件可以同时处于“已修改+已暂存+已提交”三种状态的不同组合里——看 git status 输出前，先想清楚你在哪一层操作。
