git status 是什么
git status 汇总工作区、暂存区与当前分支的关系：哪些改动已经进入暂存区、哪些还没暂存、哪些文件完全没被跟踪，以及当前分支相对上游是领先还是落后。它是提交前确认改动范围的固定动作，也是排查「文件怎么没进提交」的第一现场。
三区视角怎么看
Git 把内容分成工作区、暂存区与提交历史三层。git status 把每层差异摊开：Changes to be committed 是已暂存即将提交的内容，Changes not staged 是已跟踪但未暂存，Untracked files 是尚未纳入版本控制的文件。三者处理方式完全不同，把未跟踪文件误当已修改是最常见的误判。
基本信息
| 适用平台 | Linux / macOS / Windows（Git 2.x） |
|---|---|
| 语法 | git status [选项] [--] [路径] |
| 状态层级 | 工作区 / 暂存区 / 提交历史 |
| 常用参数 | -s 简短；-b 显示分支与领先落后；--ignored 显示忽略文件 |
| 性能相关 | 大仓库可加 -uno 或限定路径提速 |
| 是否只读 | 只读操作，不修改任何仓库状态 |
典型使用场景
- 提交前核对：确认这次提交的范围与预期一致
- 排查遗漏：文件改了却没进提交，先看它属于哪一层
- 切换分支前检查：确认工作区干净，避免改动被带过去
- 冲突处理：查看 Unmerged paths 列表逐个解决
- 脚本集成：用 --short 或 --porcelain 拿到稳定输出
- 验证忽略规则：加 --ignored 看哪些文件被规则命中
常用示例
常用示例
git status # 完整输出，含分支与各层改动
git status -sb # 紧凑格式并显示分支信息
git status --short # 两列状态码，便于扫读
git status --ignored # 一并列出被忽略的文件
git status . # 只看当前目录下的改动
git status --porcelain=v2 # 脚本友好的稳定格式输出分区怎么读
| 区块 | 含义 | 下一步 |
|---|---|---|
| Changes to be committed | 已暂存，会进这次提交 | 再用 git diff --staged 通读 |
| Changes not staged | 已跟踪但未暂存 | git add 后才会进提交 |
| Untracked files | 尚未被跟踪的新文件 | 按需 add，或补进 .gitignore |
| Unmerged paths | 冲突未解决的文件 | 编辑后 git add 标记完成 |
| ahead by N commits | 本地领先上游 N 个提交 | 需要同步时 git push |
| nothing to commit | 工作区与 HEAD 一致 | 确认是否真的没有改动 |
Untracked files 是全新文件，Changes not staged 是已跟踪文件的新改动。前者要先决定是否纳入版本控制，后者只要 add 就能进入下一次提交，处理动作并不一样。
重命名可能被显示成删除加新增。用 git status --short 配合 git diff --summary 判断 Git 是否识别为重命名，比读文字描述可靠。
跨平台项目里换行符差异也会被列为修改。先统一 core.autocrlf 或写好 .gitattributes，否则会反复出现「没改过却显示已修改」的假改动。
status 需要扫描整个工作区，超大仓库里可能明显变慢。加路径限定或用 -uno 跳过大片未跟踪目录，能显著缩短耗时，提交钩子里尤其值得注意。
两列状态码怎么看
加 --short 后每行开头有两列：左列是暂存区相对 HEAD 的状态，右列是工作区相对暂存区的状态。常见组合里 M 表示修改、A 表示新增、D 表示删除、R 表示重命名、?? 表示未跟踪。两列都非空（例如 MM）说明同一文件在两层都有改动，处理时必须分清改的是哪一层，否则容易漏提交或多提交。
两列状态码对照
| 标记 | 位置 | 含义 |
|---|---|---|
| M | 左列 | 暂存区内容相对 HEAD 被修改 |
| M | 右列 | 工作区相对暂存区又改了，尚未 add |
| MM | 两列 | 暂存区与工作区各有一次改动 |
| ?? | 两列 | 未跟踪的新文件 |
| R | 左列 | 已暂存的重命名 |
| A | 左列 | 已暂存的新增文件 |
核对改动范围的顺序是：先用 status 看清分类，再用 diff 读具体内容，最后决定 add 哪些文件。顺序颠倒容易把无关改动一起带进提交，事后返工更费时间。