Git推送新分支到origin时在压缩阶段失败如何解决

核心故障逻辑先理清 #

你遇到的这种固定在压缩阶段99%、处理文件数稳定落在5129-5137区间断开的情况，基本可以排除随机网络抖动——git bash、TortoiseGit两个完全独立的客户端都复现同样的中断位置，说明触发问题的根源是本地待推送的对象流里存在固定的异常点，不是客户端本身的bug。
很多人遇到这类问题第一反应是删本地工作区文件降体积，实际完全没碰到问题本质：Git推送传输的是.git目录下存储的全量历史对象，不是当前工作区的文件状态。哪怕你把当前工作区删到只剩原来60%的体积，只要之前提交的大文件、异常路径文件还留在历史对象里，推送的总传输量不会有任何下降——这也是你之前清理了40%工作区体积、故障依旧的核心原因。

分层排查与解决步骤 #

1. 先排除本地传输配置的兼容问题 #

先临时调整几类容易导致大对象传输被截断的Git配置，快速排除配置不兼容的问题：

• 关闭高版本HTTP协议：git config http.version HTTP/1.1。大量家用网关、企业网络设备对HTTP/2的大流量传输兼容性差，往往在传完最后一块压缩块时触发连接重置
• 调整单次请求缓冲区大小：git config http.postBuffer 52428800，将单请求缓冲区设为50MB。不要盲目把缓冲区调到GB级——过大的缓冲区会被中间网关直接判定为异常流量，主动切断连接
• 临时关闭最高压缩等级：git config core.compression 0。高压缩等级处理大对象时会占用大量CPU时间，导致本地短时间无对外数据传输，被远程服务端判定为连接空闲从而主动断开

调整完配置后重试一次推送，如果还是在同样的文件数区间断开，进入下一步定位。

2. 定位触发中断的具体问题对象 #

因为中断的文件数位置相对固定，用增量拆分推送的方式就能快速锁定问题对象，根本不需要复杂抓包：

• 不要一次性推送全分支的所有历史，先从最新的提交开始，每次拆分推送小批次的提交，比如先推最新的10个提交：执行git push origin HEAD~10:debug-test。如果能推送成功，就继续往前推下10个提交，直到推送时再次出现固定位置的连接断开
• 锁定中断的提交范围后，逐次缩小批次量，直到精准定位到具体是哪一个提交触发的中断
• 检查这个提交里的两类高频异常对象：
  • 单个体积超过远程仓库限制的大文件：绝大多数个人Git托管服务的单文件硬限制在100MB左右，达到这个大小的文件在压缩完成、准备传输时会被服务端直接拒绝连接，不会弹出明确的错误提示
  • 之前OneDrive恢复遗留的异常文件：比如带特殊控制字符的文件名、非UTF-8编码的路径、超过260字符的超长路径，这类文件在服务端解析时会直接触发进程崩溃，表现为连接无响应被切断

3. 针对性解决问题对象 #

• 如果是历史提交里的超大文件：不要只在当前工作区删除文件，需要通过Git历史重写的方式，把这些大对象从分支的历史提交中彻底剔除，清理完本地对象存储后再推送，才能真正降低传输体积
• 如果是超长路径/编码异常的文件：先开启Git的长路径支持：git config core.longpaths true，再把对应文件重命名为符合Git规范的UTF-8短路径名称，重新提交对应变更后再推送
• 如果换手机热点等其他网络环境就能成功推送，说明是原有网络的网关对长连接大流量做了超时限制：这类情况不需要修改仓库内容，调整本地MTU值或者走合规的代理通道传输即可解决

避坑提醒 #

• 反复在git bash、TortoiseGit之间切换重试没有意义：两个客户端调用的是同一套本地Git对象存储，只要触发问题的对象没有被处理，换任何第三方Git客户端都只会复现同样的故障
• 只删除当前工作区的旧文件、不清理历史大对象没有效果：这是大体积个人Git仓最容易踩的误区，工作区的文件体积和Git推送需要传输的历史对象体积完全是两个独立的统计维度

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