离线文本版 · Markdown 标记与示例按原文保留。
> 日期说明：归档日期为历史整理日期，不代表原始首发时间；本文于 2026-11-02 核对并修订。命令示例需按实际环境替换占位符。 把配置修复、样式修改和内容更新分开提交，回头查看时更容易理解变化。本文整理两个容易忽略的环节，作为日常使用时的检查参考。 <!-- more --> ## 一次提交回答一个问题 把配置修复、样式修改和内容更新分开提交，回头查看时更容易理解变化。提交信息应描述具体结果，而不只是写 update 或 fix。 ## 提交前看一遍差异 git diff 能发现意外格式化、敏感文件和漏改的配置。生成目录、缓存与本地凭据通常不应进入版本控制。忽略文件只能阻止未跟踪文件，已经提交的内容需要另行处理。 ## 日常使用的小结 Git 保存历史，但不能替代异地备份。为重要仓库设置独立远端，并定期确认本地提交真的已推送。 ## 操作参考与适用边界 ### 提交前后核对 ```sh git status --short git diff --check git diff --stat git log -5 --oneline ``` diff --check 只能发现部分空白错误，不会检查功能。推送前仍需人工审核 diff，并确认没有把本地运行数据或凭据加入暂存区。 ### 如何判断结果 操作后应将实际结果与文中目标对照；命令成功退出只能证明该步骤完成，不能替代业务层验证。记录异常信息时，保留时间、软件版本与相关上下文，方便后续复查。 ## 参考资料 - [官方文档与规范](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository)（本次整理参考，页面内容可能随版本更新） - [继续阅读本站归档](/archives/)