Git add、commit、status 入门：把一次修改准确放进提交
保存文件以后，Git 为什么还提示没有可提交的内容？刚刚执行过 git add，为什么同一文件又出现在未暂存列表？这些问题通常不是工具故障，而是把“编辑文件”和“准备提交”当成了同一件事。
本文用一个文档项目说明基本流程。命令用于教学，不代表作者在你的仓库中执行过；示例文件名需要替换为真实路径。操作前请确认终端所在目录是目标仓库，重要的未提交内容另有备份。
一、先分清三个位置
工作区是编辑器正在修改的文件。暂存区是为下一次提交准备的内容，也称索引。提交记录则是已经写入 Git 历史的快照。
git add 把指定路径当时的内容放入暂存区。它不是给文件安装一个“以后所有修改自动提交”的开关。如果暂存后又继续编辑，新的修改仍需再次暂存。Git 官方文档也允许使用 git add -p 按修改片段选择内容，适合一个文件中混有多个独立任务时使用。Git add 文档
可以把暂存区理解为一次交付的装箱清单。写作桌上放着所有草稿，但这次交付只装入已经检查好的那几页。这样做的目的不是增加步骤，而是让一次提交表达一个清楚的意图。
二、先看状态，不急着暂存全部文件
进入仓库后运行：
git status
重点阅读三类内容：已经暂存、修改但未暂存、未跟踪。初学阶段保留完整输出，通常比只记住几个字母更容易理解。熟悉以后可以查看简短格式：
git status --short
下面是用于解释格式的示意，不是实测输出：
M README.md
A docs/setup.md
MM docs/usage.md
?? notes.txt
普通、无合并冲突的场景中，前两列分别描述暂存区状态与工作区状态。第一行表示修改尚未暂存；第二行表示新文件已经暂存；第三行表示存在已暂存版本，同时工作区又出现后续修改；第四行表示文件尚未被跟踪。遇到冲突时两列含义不同，不要套用这套简化解释继续提交。Git status 文档
这里最值得养成的习惯是先问“这些变化是不是我这次想交付的”。如果状态列表出现不认识的配置文件、输出目录或数据库备份，先停下来检查来源，而不是为了让列表干净而一起加入。
三、用差异确认实际内容
状态告诉你哪些文件变了，差异告诉你具体变在哪里：
git diff
git diff --cached
第一条查看工作区相对暂存区的改动，第二条查看暂存区相对当前提交的改动，也就是普通提交将包含的主要内容。新建但尚未跟踪的文件通常不会出现在普通 git diff 中，因此还要用编辑器查看它们，不能把空白输出理解为整个目录没有新内容。Git diff 文档
检查时建议分两遍：第一遍看逻辑，比如示例中的目录是否一致；第二遍看意外内容，比如账号、密钥、临时日志和个人绝对路径。命令执行成功只说明 Git 接受了操作，不说明材料已经适合共享。
四、明确指定文件，再提交
假设本次只修正文档说明，可以按顺序执行：
git add -- README.md docs/setup.md
git status
git diff --cached
git commit -m "docs: clarify installation prerequisites"
git status
-- 用于分隔选项与路径。带空格的路径要加引号，例如 git add -- "docs/setup notes.md"。明确列出路径比直接收集整个目录更适合刚接触项目的人；但最终仍应检查暂存区，因为那里可能已经有此前暂存的其他文件。
普通的 git commit -m 使用暂存区创建本地提交；它不是上传操作。-m 后面是提交说明，建议描述这次修改的目的。git commit -a 会自动处理已跟踪文件的修改和删除，却不会把全新的未跟踪文件自动纳入，因此不能把它当作“提交所有文件”的通用快捷方式。Git commit 文档
一个好的提交说明应该帮助几周后的自己回答“为什么改”，而不只是“今天修改”。例如“补充安装前的版本检查”比“更新文件”更容易定位。这个建议是工作组织方式，不是 Git 对提交信息的语法要求。
五、几个容易踩中的误区
误区一：暂存以后就可以继续编辑，再直接提交。 如果继续编辑是为了修复刚才的错误，应重新检查和暂存对应路径。不然提交的仍可能是较早版本。
误区二：状态干净就表示已经备份到远端。 工作区是否有变化与远端是否收到提交是两件事。不要把本地状态当作远程服务的确认通知。
误区三：把秘密文件加入忽略规则，就能消除泄露。 .gitignore 面向尚未跟踪的文件，不会让已经跟踪的内容自动消失，也不会清除既有历史。如果凭据已经暴露，应按所属服务的安全流程处理失效与更换，不能只改忽略规则。Git ignore 文档
误区四：一次提交越大越省事。 把排版、功能修正和配置迁移混在一起，后续审查会更困难。可以先完成一个目标，检查、提交，再处理下一个目标。提交前的测试也应与修改匹配：改文档至少检查链接与示例，改代码则执行项目规定的验证。
六、记住一条可重复的节奏
日常使用不必先记完所有 Git 选项。先形成“看状态、看差异、选文件、再看暂存差异、提交、复查状态”的节奏。遇到错误先读完整提示，不用随机复制会改写历史或删除文件的命令来消除报错。
本文的边界是制作可理解的本地提交，没有涉及远端上传、冲突处理或历史重写。把这一步做准确，后面的协作流程会容易得多。