04.一次 Git 提交前后，应该检查什么？

从普通目录完成第一次本地提交并不难，但真实开发很少一直保持“只修改一个文件，然后立即提交”的理想状态。

写一个功能时可能同时出现：

• 当前真正要提交的代码；
• 顺手修改但应单独提交的文档；
• 运行程序产生的日志；
• 只属于本机的环境配置。

这时，add 和 commit 本身并不难，真正需要判断的是：

哪些变化属于这次提交，哪些应该留在外面？

四个检查窗口

一次提交前后，可以从四个角度观察仓库：

status 先告诉我们“哪里有变化”，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-blog@example.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 .，就可能把它们一起放入暂存区。

在仓库根目录创建 .gitignore：

printf "*.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.txt

debug.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.txt

app.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 HEAD

HEAD 表示当前检出位置对应的提交。在通常的分支状态下，它通过当前分支定位到最新提交。

确认功能提交没有混入 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.txt

Git 会把变化分成若干块，让我们逐块决定是否暂存。没有选中的部分仍留在工作区，不会被删除。

完成后分别检查：

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 Repository
• Git 官方资料：Viewing the Commit History
• Git 官方文档：git-status
• Git 官方文档：git-diff
• Git 官方文档：git-add
• Git 官方文档：git-commit
• Git 官方文档：git-log
• Git 官方文档：git-show
• Git 官方文档：gitignore