git push卡住主因是传输链路阻塞：http.postBuffer过小、SSH未启用ControlMaster、UseDNS导致DNS查询延迟、代理截断大请求或历史大文件拖累打包。需调大http.postBuffer与maxRequestBuffer、禁用UseDNS、配置SSH连接复用，并清理误提交大文件。
Git 提交代码到远程仓库本身不耗时，真正卡住的环节是 git push 传输阶段——不是你本地 commit 慢，而是把对象打包、压缩、上传、校验的过程被拖慢了。核心问题集中在协议层、缓冲区、压缩策略和网络中间件上。
为什么 git push 卡在 “Writing objects” 或 “Counting objects” 后不动
这通常不是 Git 本身的问题，而是传输链路中的某一个环节被堵住：
-
http.postBuffer太小：默认值仅 1MB，推大文件或批量提交时直接触发RPC failed; HTTP 500或静默卡死 - 服务端启用
UseDNS：SSH 推送时反复做反向 DNS 查询，卡在connecting to host...长达 10–15 秒 - 代理或防火墙截断大请求：企业网络常限制单次 POST 长度，
http.maxRequestBuffer不设会导致连接中断 - 未启用 SSH 连接复用：每次
push都重走三次握手 + 密钥交换，小团队高频推送时开销明显
http.postBuffer 和 http.maxRequestBuffer 必须调大
这两项是 HTTPS 协议下最常被忽略的性能开关，尤其在推含大文件、子模块或深度历史的仓库时：
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 执行
git config --global http.postBuffer 524288000（500MB），覆盖绝大多数单次推送场景 - 执行
git config --global http.maxRequestBuffer 100M，防止 Nginx、Traefik 或企业网关主动断连 - 顺带加上
git config --global core.compression 9，压缩率拉满，传输体积减少约 40%，CPU 开销可忽略
SSH 推送务必启用 ControlMaster 并禁用 UseDNS
如果你用的是 git@gitlab.com:xxx 这类 SSH 地址，但推送仍慢，大概率是连接建立成本太高：
- 客户端配置：在
~/.ssh/config中为对应 Host 添加：ControlMaster autoControlPersist 4hControlPath ~/.ssh/sockets/%r@%h:%p - 服务端配置（需有服务器权限）：编辑
/etc/ssh/sshd_config，确认含UseDNS no，然后sudo systemctl restart sshd - 验证是否生效：首次
git push仍会建连接，第二次起几乎无感知；ssh -v git@host日志里不再出现Trying to reverse map address
别让大文件污染推送流程
即使你没主动加过大文件，.git/logs/、.git/index 或误提交的二进制资源（如 .zip、.dll）也会让每次 push 反复打包传输：
- 运行
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}')"找出最大的几个对象 - 确认是误提交后，用
git filter-repo --invert-paths --path bad-file.zip清理（比filter-branch快且安全） - 后续统一用
git-lfs track "*.psd"管理大文件，避免再次拖慢推送
真正影响 git push 速度的，从来不是你的网速，而是配置是否绕开了那些默认的保守限制。改完 http.postBuffer 和 ControlMaster，再清理一次历史里的大文件，90% 的“推送慢”问题就消失了——但很多人卡在第一步，连 git config --list | grep post 都没查过。
