Git push报错fatal: the remote end hung up unexpectedly如何解决

从返回日志可定位两个直接诱因：

• 协议兼容问题：Git默认使用HTTP/2协议传输时，中间链路（代理、网关、服务端流控策略）会主动截断大体积长连接，直接触发curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)报错
• 体积超限问题：本次推送总包体积达2.37GiB，极易触发Git默认HTTP传输缓存阈值、或远程仓库单批次推送大小限制，最终导致远端主动挂断连接。

• 强制Git使用HTTP/1.1协议传输
  这是解决该curl报错的最高频有效方案，执行对应命令配置即可：
  全局生效（所有仓库复用该配置）：

  git config --global http.version HTTP/1.1
  

  仅当前仓库生效（在项目根目录执行）：

  git config http.version HTTP/1.1
  

  配置完成后直接重新执行git push即可。

• 调大Git HTTP传输缓存上限
  针对大体积推送场景，将缓存阈值调整为5GiB，避免缓存不足导致的传输中断：
  全局生效：

  git config --global http.postBuffer 5242880000
  

  仅当前仓库生效去掉--global参数即可，配置后重试推送。

• 排查代理链路问题
  如果本地开启了系统代理、VPN工具，先临时关闭后重试推送。多数代理节点对HTTP/2大流量长连接有强制截断策略，是该错误的常见触发源。

• 分批拆分推送
  如果以上方案都无效，不要一次性推送全量2.37GiB内容，拆分提交逐次推送：

  1. 先执行命令查看本地未推送到远程的提交列表：

     git log --oneline origin/<你的远程分支名>..HEAD
     

  2. 从最早的未推送提交开始，逐次指定提交哈希推送到远程，控制单次推送体积在500MiB以内：

     git push origin <提交哈希值>:<远程分支名>
     

• 大文件适配
  如果仓库内存在单文件体积超过100MiB的资源，直接推送会被多数Git服务端拦截，先安装Git LFS追踪对应大文件格式后再执行推送。

重新执行git push时，不再出现流关闭异常、远端意外挂断的报错，能正常显示推送进度条、最终返回分支更新成功的提示即为修复完成。

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