从普通目录完成第一次本地提交并不难但真实开发很少一直保持“只修改一个文件然后立即提交”的理想状态。写一个功能时可能同时出现当前真正要提交的代码顺手修改但应单独提交的文档运行程序产生的日志只属于本机的环境配置。这时add和commit本身并不难真正需要判断的是哪些变化属于这次提交哪些应该留在外面四个检查窗口一次提交前后可以从四个角度观察仓库想知道什么命令哪些路径发生了变化分别位于哪一层git status --short工作区相对暂存区还有哪些具体变化git diff暂存区相对当前提交准备记录什么git diff --cached也可以使用git diff --staged提交完成后形成了什么历史git log --oneline、git showstatus先告诉我们“哪里有变化”diff再说明“内容怎样变化”log和show用于提交后核对已经形成的记录。准备独立实验仓库下面的初始化和第一次提交只用于建立可复现的前置状态。如果本地已有同名目录请换一个新名字。mkdir commit-check-lab cd commit-check-lab git init git config user.name Git Blog Lab git config user.email git-blogexample.invalid printf login validation\n app.txt printf old documentation\n README.md git add app.txt README.md git commit -m chore: initialize commit check lab现在仓库有一个初始提交工作区是干净的。先处理不应进入仓库的文件运行程序时经常产生日志本地开发也可能需要只属于个人环境的配置。先制造两个未跟踪文件printf debug output\n debug.log printf local development configuration\n .env git status --short输出会包含?? .env ?? debug.log它们都是工作区中的未跟踪文件。如果直接执行git add .就可能把它们一起放入暂存区。在仓库根目录创建.gitignoreprintf *.log\n.env\n .gitignore git status --short现在输出中不再显示debug.log和.env只会出现新的.gitignore?? .gitignore忽略规则本身是项目约定应该进入版本历史git add .gitignore git commit -m chore: ignore logs and local environment files.gitignore 的两个边界第一.gitignore主要影响尚未被跟踪的路径。文件如果已经进入提交后来补写忽略规则不会自动停止跟踪。如果误跟踪的是普通日志或本地生成文件可以在写好忽略规则后停止跟踪git rm --cached 文件 git add .gitignore git commit -m chore: stop tracking generated file--cached会把删除记录放入暂存区但保留本地工作区文件。目录需要配合-r使用。执行后应先用git status确认暂存内容再提交这次规则变更。第二忽略规则不是凭据泄露后的补救工具。密钥、Token 或密码一旦进入历史应立即轮换或作废再根据团队流程处理仓库历史。仅仅删除文件或补写.gitignore不能让已经泄露的值失效。制造一个混合修改现场printf check empty username\n app.txt printf new usage example\n README.md printf another debug line\n debug.log git status --short输出M README.md M app.txtdebug.log仍存在于本地但因为匹配.gitignore不会出现在普通状态结果中。git status --short在文件名前使用两个位置显示状态可以写成XY 文件名第一个位置X已经进入暂存区的变化第二个位置Y仍在工作区、尚未暂存的变化。当前两个文件显示为M第一个位置为空第二个位置是M说明文件只在工作区发生了修改还没有进入暂存区。diff检查具体改了什么先检查准备作为当前功能提交的文件git diff -- app.txt这里会看到新增的check empty username。再检查文档git diff -- README.md这里会看到另一个独立意图补充使用示例。普通git diff比较工作区和暂存区不会展示普通未跟踪文件的内容。因此检查现场时不能只看diff还要先看status否则可能漏掉尚未跟踪、也未被忽略的文件。只选择属于本次提交的变化这次先提交登录校验不把文档修改混进去git add app.txt git status --short输出M README.md M app.txtapp.txt的M进入左列说明它已经被暂存README.md的修改仍在工作区。提交前检查暂存区中的实际内容git diff --cached -- app.txt这里只应该出现与登录校验有关的变化。确认边界正确后再提交git commit -m feat: validate empty username一次提交可以同时包含代码、测试和必要文档关键不是“只能改一个文件”而是这些变化能否共同表达同一个意图并且可以一起评审和撤销。提交后不要立即离开提交完成后先看状态git status --short输出M README.md这说明功能变化已经提交文档修改仍然安全地留在工作区。提交不会自动带走没有进入暂存区的变化。接着查看最近历史git log --oneline -3它用于快速确认最近提交的顺序和说明。查看刚才那次提交涉及哪些文件git show --stat HEAD查看提交的完整内容git show HEADHEAD表示当前检出位置对应的提交。在通常的分支状态下它通过当前分支定位到最新提交。确认功能提交没有混入 README 后再把文档作为独立提交git add README.md git diff --cached -- README.md git commit -m docs: add usage example git status最后的状态应该是干净的。同一个文件包含两个意图怎么办按路径执行git add app.txt会选择这个文件当前的全部变化。但同一个文件也可能同时包含两个不同意图。此时可以交互式选择差异块git add --patch app.txtGit 会把变化分成若干块让我们逐块决定是否暂存。没有选中的部分仍留在工作区不会被删除。完成后分别检查git diff --cached -- app.txt git diff -- app.txt第一条查看已经选入下次提交的变化第二条查看仍留在工作区的变化。如果一个差异块内部仍然混着两个意图可以继续拆分差异块或者先回到编辑器整理内容。为什么不把 commit -am 当作默认动作git commit -am message这个写法会在提交前自动暂存所有已跟踪文件的修改和删除并提交它们执行命令时的当前内容但不会纳入普通未跟踪文件。它也会绕过“选择路径 → 检查暂存差异”的过程。如果同一个已跟踪文件在暂存后又继续修改-a会把后续工作区修改一起纳入提交可能破坏原本选择好的边界。只有当所有已跟踪变化都属于同一意图并且已经确认过现场时它才比较合适。一次提交前后的稳定检查顺序git status --short ↓ git diff ↓ 排除不应跟踪的路径选择本次相关变化 ↓ git diff --cached ↓ git commit ↓ git status --short ↓ git log --oneline / git show提交之前检查选择提交之后核对结果。暂存区不是必须机械经过的一步而是编辑下一次历史记录的地方。总结一次清晰的提交不是靠一句漂亮的提交说明产生的而是从检查现场、排除无关文件、选择同一意图的变化开始。status定位路径diff核对内容暂存区确定边界log和show则帮助确认最终写入了怎样的历史。参考资料Git 官方资料Recording Changes to the RepositoryGit 官方资料Viewing the Commit HistoryGit 官方文档git-statusGit 官方文档git-diffGit 官方文档git-addGit 官方文档git-commitGit 官方文档git-logGit 官方文档git-showGit 官方文档gitignore