这个坑，我踩得挺疼的。
当时的情况是这样的：
我push了一批文章到GitHub。
结果超时了。
网络问题，我想。那再push一次吧。
又超时了。
算了，等会再试。
过了五分钟，我又push了一次。
这次成功了。
然后我去Vercel看部署状态，发现——
文章出现了两次。
对，重复的。
排查了一下，发现第一次push其实成功了，后面两次是多余的，导致了重复提交。
浪费了时间，还弄出了脏历史。
问题在哪
问题在于：git push超时，不等于push失败。
Git的push操作分两步：
- 本地数据上传到远程
- 远程返回确认信息
网络不稳定的时候，第二步可能超时，但第一步已经完成了。
这时候push其实成功了，只是你收不到确认。
如果你再push一次，就重复了。
怎么判断push到底成没成
方法一：git log
git log --oneline -5
看看最近的提交记录。
如果看到你刚才的commit，说明push成功了。
方法二：git status
git status
如果显示nothing to commit, working tree clean，说明本地没有待提交的改动。
结合git log，基本可以确认push成功了。
方法三：Vercel dashboard
去Vercel看构建记录。
如果看到新的构建触发了，说明代码已经push成功。
遇到超时的正确做法
第一步：别急着重试。
先等一两分钟，网络可能自己恢复了。
第二步：确认状态。
用上面的方法查git log或者Vercel。
第三步：确认push成功了，再决定要不要重试。
如果确认没push成功，再重试。
另一个坑：URL查不到
我之前还踩过另一个坑。
push成功了，Vercel也构建完了，但网站上看不到新文章。
我第一反应是：是不是没push上去？
又push了一次。
还是看不到。
后来才发现：
Hugo文章的URL不是文件名，是frontmatter里的slug。
我文件名是my-first-post.md，但slug写的是first-article。
所以访问/posts/my-first-post/是404，要访问/posts/first-article/才行。
查不到不等于没上线。
URL可能是中文slug或者frontmatter里定义的slug，不是文件名。
防止重复push的习惯
怎么避免重复push？
习惯一：push前先git status
看看有没有待提交的改动。
有改动才push，没有改动就别push。
习惯二：用–quiet
git push --quiet
这样不会显示详细输出，减少干扰。
但更重要的还是，先确认状态再行动。
习惯三：push后等一两分钟再看Vercel
Vercel构建需要时间。
刚push完就刷新，可能还在构建中。
等一两分钟再看，或者看Vercel的邮件通知。
总结
git push超时的正确处理：
- 别急着重试，先等一两分钟
- 用
git log确认提交记录 - 确认push成功了，再决定要不要重试
另一个坑：
- 查不到不等于没上线
- URL可能是中文slug或frontmatter里定义的slug，不是文件名
网络不稳定是常事，别慌。
确认状态，再行动。