保存、提交、推送，到底差在哪？

01保存：把编辑结果写入文件

假设我在首页加入“访问我的 GitHub”链接。按下保存后，变化写入电脑上的 index.html；刷新本地页面，就能检验它能不能跳转。此时 GitHub 和线上网站并不会因为保存而自动改变。

编辑器里的文字、磁盘里的文件和网站上的内容可能暂时处于不同状态。排错时先确认保存的是当前项目中的文件，再确认浏览器打开的是本地预览还是线上网址，可以避免在错误的位置反复刷新。

02暂存：选择这次提交包含什么

暂存的作用，是选出准备记录到下一次提交里的内容。例如这次只增加链接，就可以先检查 index.html 的差异，再把它暂存；还没完成的其他调整可以留在工作目录。

有个容易忽略的细节：暂存后又继续修改文件，新的修改不会自动进入已经暂存的版本。提交前需要再次检查差异，必要时重新暂存。所以，同一个文件同时出现在“更改”和“暂存的更改”中，并不一定是故障。

03提交：在本地留下一个版本

提交把暂存的内容记录进本地历史，并附上说明。相比“修改一下”，写成“添加 GitHub 链接”更容易让未来的自己理解这一步做了什么。一次提交最好对应一块完整、可以解释的改动。

这个版本仍然保存在本地。提交完成不等于已经上传，也不等于已经部署。可以先在源代码管理里检查文件变化，再查看最近的提交；如果记录符合预期，下一步才是把它同步给远程仓库。

保存 → 文件发生变化
暂存 → 选入下一次提交
提交 → 记录到本地历史
推送 → 把提交发送到远程仓库

04推送以后，仍然要检查部署

推送把本地提交发送到 GitHub。对于已经连接 Pages 自动部署的本站，GitHub 收到提交后，托管平台才会继续处理上线。GitHub 上有新版本，只能证明代码已到达远程；页面是否更新，还要看部署结果。

如果网站没有变化，先对照 GitHub 最近提交与 Pages 部署记录，再检查实际页面。推送遇到拒绝时，要先理解远程是否有新改动，不应靠反复点击或强制推送解决。保留明确的版本记录，比凭页面颜色判断更可靠。

新增头像时，记得同时检查图片文件是否纳入提交。页面在本地能找到图片，不代表远程仓库也有它。一次完整的修改，应包含页面实际引用的必要文件。

• 提交前检查差异，确认没有混入无关文件
• 推送后确认 GitHub 已显示目标提交
• 部署成功后检查线上页面和样式