如何排查GitHub推送master分支缓慢且超时的问题？

这问题我碰到过好几次——明明只改了几个小脚本，推送却慢得像在传大文件，最后还超时，着实头疼。给你分方向梳理几个排查和解决思路：

一、先确认你到底在推送什么 #

有时候表面上的修改和实际要推的内容完全两回事：

• 模拟推送看细节：执行git push --dry-run，这个命令会模拟推送流程但不会真的把内容传到远程，输出里会显示要推送的提交、涉及的文件，如果有意外的大文件或者大量文件，这里一眼就能看到。
• 检查仓库对象大小：跑git count-objects -v，看看size-pack的值（这个是仓库打包后的总大小），如果数值异常大，说明历史里可能藏着已经删除但没清理的大文件。这时候可以先试试git gc --prune=now清理本地的垃圾对象；如果还是不行，就得用git filter-repo彻底移除历史中的大文件（注意：这个操作会改写提交历史，要是团队协作的仓库，一定要提前和队友沟通好）。
• 列出当前提交的所有文件：用git ls-tree -r HEAD --long，能看到当前提交里每个文件的大小，排查有没有某个Python脚本实际偷偷包含了大内容（比如不小心把二进制数据写到脚本里了？）。
• 检查被忽略的文件：执行git status --ignored，看看有没有被.gitignore规则排除的文件被意外追踪了——有时候不小心用git add .把不该加的文件提交了，自己还没注意到。

二、排查网络和远程配置问题 #

如果内容没问题，那大概率是网络或配置的锅：

• 测试远程连接速度：先试试git fetch拉取远程最新内容，如果拉取也慢，那基本是网络问题——换个网络（比如从公司内网切到手机热点），或者检查Git的代理设置：git config --global --get http.proxy，如果有不需要的代理，用git config --global --unset http.proxy关掉。
• 切换推送协议：如果之前用的是HTTPS协议，换成SSH试试（先确保本地配置了SSH密钥）。不少情况下，SSH的推送稳定性比HTTPS好，尤其是在网络波动的环境下。
• 调大推送缓冲区：执行git config --global http.postBuffer 524288000（把缓冲区设为500MB），有时候默认的缓冲区太小，哪怕是正常的推送也会因为分块传输导致超时。
• 检查远程地址正确性：跑git remote -v确认你推的是正确的origin/master，别不小心推到其他仓库去了。

三、其他排查小技巧 #

• 看详细推送日志：执行git push --verbose，这个命令会输出推送的每一步细节——比如是卡在“Compressing objects”（本地压缩对象）还是“Writing objects”（传输到远程），根据卡住的阶段能更快定位问题：如果卡在压缩，说明本地对象有问题；卡在传输，就是网络或远程仓库的问题。
• 检查仓库完整性：用git fsck检查本地仓库有没有损坏的对象，偶尔仓库损坏也会导致推送异常，如果有损坏提示，可能需要重新克隆远程仓库。
• 先拉再推：如果是多人协作的仓库，先执行git pull --rebase拉取远程最新内容，解决可能的冲突后再推送——有时候冲突导致的异常处理也会让推送变慢。

内容的提问来源于stack exchange，提问作者triphook