阅读Git status：区分修改、暂存与未跟踪文件

从修改文件到准备提交

步骤1	修改并保存当前文件
步骤2	用status确认状态
步骤3	用diff确认尚未准备的修改
步骤4	暂存所需文件
步骤5	用cached diff确认已准备内容

这是整理阅读顺序的说明图，并非实际程序画面或测量结果。

初次使用Git时，可能已经保存文件却出现“没有可提交的修改”，或明明修改了一个文件，却发现它同时出现在两个列表中，令人困惑。要理解这些情况，应分别考虑当前文件、准备放入下一次提交的内容，以及最后一次提交。git status是阅读这些差异的基础工具。

这里说明如何在一般Git仓库中区分修改、暂存与未跟踪文件。命令和输出是帮助理解的虚构示例，并非在读者实际仓库中运行的结果。本文集中介绍先确认状态与差异的流程，而不是从删除修改的命令开始。

1. 区分工作目录、暂存区与提交

工作目录是存放当前在编辑器中阅读、修改的文件的空间。暂存区是汇集下次提交所含内容的状态，也称索引。最后一次提交是已经记录的快照。git status展示这些状态之间的差异与未跟踪文件等。按下保存按钮，与记录到Git提交中，是不同事实。

git add是准备将当前修改放入下次提交的操作。准备后再修改同一文件，暂存区与当前文件就可能不同。此时，一个文件可能同时出现在待提交修改与尚未暂存修改的列表中。不要认定为错误，应分别查看两种差异。

假设在虚构的note.txt中写入第一句话并暂存后，又添加第二句话。下次提交准备的是第一阶段的文件，而工作目录中已有新增句子。如果也要将第二句话放入此次提交，应确认当前修改后再次暂存。出现一个文件名，并不意味着该文件最新内容全部已经准备。

2. 确认仓库位置并阅读基本状态

先确认终端位于正确项目中。在其他文件夹运行命令，可能无法看到目标仓库状态。如果出现不是Git仓库的错误，不要立即创建新仓库，应先确认当前路径与原项目文件夹。如果项目本身已有Git记录，首先应在那个位置阅读状态。

基本命令是git status。普通输出可查看当前分支、已准备修改、尚未准备修改与未跟踪文件等列表。措辞可能随语言、设置与正在进行的工作而异，因此应确认列表含义。本文英文表述与自己的画面不同，并不需要认定功能改变。

虚构输出中，“Changes to be committed”表示已为下次提交准备的修改，“Changes not staged for commit”表示当前文件与已准备内容之间的修改，“Untracked files”表示Git尚未跟踪的文件。打开列表中的文件后，再决定哪些修改纳入本次工作。一次添加所有文件前，最好确认目的。

git status
git diff
git diff --cached

上述三个命令是阅读状态与差异的基本示例。git diff通常用于确认尚未暂存的修改，git diff --cached用于确认相对于最后一次提交的暂存内容。实际命令的详细行为与选项，应查看当前Git官方文档。

普通列表	含义	首先进行的确认
待提交修改	为下次提交准备的内容	通过git diff --cached确认实际内容
尚未暂存的修改	当前文件与已准备内容的差异	通过git diff确认
未跟踪文件	尚未添加到索引的文件	确认是必要源码还是临时、生成文件
冲突相关状态	合并过程中需要处理的项目	先确认冲突内容与正在进行的工作

3. 简短输出的两栏代表不同的比较

运行git status --short后，文件前会出现两个字符的状态。在一般非冲突情境中，第一栏X表示索引状态，第二栏Y表示工作目录状态。即使都是M，位置不同，含义也不同。空格也有意义，因此不要把两栏合成一个字符来阅读。

虚构输出“M app.py”是第一栏为M的例子，“ M app.py”是第二栏为M的例子。“MM app.py”可能表示同时存在已准备修改与之后的工作目录修改。在这种状态下提交时，不要认为当前文件全部修改会自动纳入，应直接查看暂存差异。

未跟踪文件用??表示。A可以表示新增，D表示删除，R表示重命名等。正在发生合并冲突时，相同两栏按独立规则解释，因此不能只依据普通规则阅读。如果看到U或unmerged相关提示，应查看官方状态表与冲突解决指南，先了解正在进行的工作。

虚构的简短输出	一般非冲突情境中的解释	需要确认的差异
M app.py	修改内容已暂存	为提交准备的修改
M app.py	在工作目录中修改	尚未准备的修改
MM app.py	暂存后又进行了额外修改	分别确认两种修改
A new.txt	新文件已暂存	文件内容与纳入目的
?? temp.txt	未跟踪文件	判断跟踪还是忽略

4. 新文件没有显示时应确认的内容

创建新文件后，如果列表中没有出现，应先确认文件实际保存以及项目路径。然后可以查看是否匹配忽略规则。符合.gitignore的文件通常会从未跟踪文件列表中排除。状态输出选项或设置也可能隐藏未跟踪文件，因此应确认当前命令与设置。

忽略规则应根据文件目的判断。构建结果、缓存与环境特定设置等，可按项目政策排除。反过来，如果实现功能所需源码被意外忽略，就需要审查规则。与其因为新文件没有显示就强制添加所有忽略文件，不如先了解相关规则与文件。

已跟踪文件不会因为在.gitignore中加入名称，就自动停止跟踪。已记录文件与尚未跟踪文件的处理不同。如果不小心跟踪了含敏感值的文件，不能认为仅隐藏列表就解决了历史记录中的暴露问题。可能需要相应的仓库管理与凭证处理。

5. 阅读并准备一个文件的小步骤

虚构工作中，如果只修改app.py，应先用git status确认状态，再用git diff -- app.py阅读修改。确认属于必要修改后，可用git add -- app.py进行准备。之后用git diff --cached -- app.py阅读要纳入下一次提交的内容是否正确，再次确认git status。

这个顺序对新文件或大型工作也有相同基本原则，但可能需要同时查看新文件内容、生成结果与多文件依赖关系。逐文件准备，并不意味着功能互不相关，因此应考虑一个功能所需的修改集合。同时也应确认范围，避免纳入其他工作的修改。

提交前，应确认修改内容，再进行该功能所需验证。status干净，不代表测试已经通过；已经提交，也不保证运行结果正确。状态确认是管理记录哪些内容的步骤，功能确认则是判断代码是否执行所需行为的独立步骤。

6. 三种常见混淆情况

第一，在编辑器保存但未暂存，可能没有已准备修改。第二，暂存后再次修改文件，可能同时出现在两个列表。第三，未跟踪新文件如果提交前没有添加，就不会进入此次提交。这三种情况都应查看索引与当前内容的差异，而不只是文件名，这样更容易理解。

在虚构团队工作中，如果状态列表中有其他人创建的文件，不要立即认定是自己的修改。应确认谁正在做什么工作，以及当前检出的修改。为了让状态干净而删除或回退列表中的修改，可能会丢失必要工作。状态列表是理解当前工作的资料，而不是要删除的清单。

如果正在合并、变基或解决冲突，应与普通修改工作区分。阅读status显示的进度与相关文件，了解处于哪个阶段。不要在不了解命令含义时连续执行提示中的多个操作，应先确认工作目的与需要保留的修改。通过只读命令进行确认，可以为下一步选择建立依据。

提交前留下的简短记录

记录“当前分支、本次纳入文件、已确认暂存差异、功能验证结果、尚未准备的修改”，可以方便进入下一项工作。如果文件同时出现在两个列表，应写明后续修改是什么。即使仍有未纳入修改，只要是预期状态，也可以记录原因。

一次记住的核心有三项：文件保存是保存当前文件，git add是准备下次提交，提交则是记录已准备内容。阅读git status时，将各列表与两栏的含义联系起来，就能区分新文件与修改文件的状态，谨慎记录必要修改。

官方资料与确认范围

• Git官方git-status文档
• Pro Git：将修改记录到仓库

资料确认日期：2026年10月5日。本文由AI查阅官方资料后编写。文中虚构案例与计算示例，并非实际用户记录或实验结果。服务条件、菜单及公开资料可能变化，必要条件请查阅当前官方指南。