git push到GitLab仅改单文件却传全量且卡住，配置无效求助

• 本地仅修改单个文件，但执行push时累计需上传358个Git对象、总计27.78MiB内容，进度显示100%上传完成后无后续输出，流程卡住
• 已尝试全局/本地关闭sendpack.sideband、调整http.postBuffer为824288000，以上操作均未解决问题

两个看似独立的现象本质是连续链路的问题，和你之前调整的配置参数没有关联：

1. 仅改单文件却要传全量内容：
   • 你看到的Writing objects: 100%输出只代表本地端到网络链路的传输完成，不代表远程仓库已经收到完整内容
   • 358个对象、27M的体积不是本次单文件修改带来的，要么是本地仓库基于过旧的远程版本拉取，积累了大量未同步的历史提交；要么是之前的提交历史中留存了大文件对象，哪怕当前本地文件已经删除，Git的版本历史里依然会保留这些大文件，打包推送时会一并上传
2. 传输完成后卡住无输出：
   • 出现Total 358 (delta 244), reused 6 (delta 2), pack-reused 0提示时，本地端的上传动作已经全部结束，后续没有输出是因为本地在等待GitLab服务端的处理响应，不是传输还在跑
   • 常见的服务端卡点：
     • 上传的打包内容触发了GitLab的单文件大小拦截规则（GitLab默认单文件限制为10MB，就算你本地调整了缓冲区大小，服务端的硬限制依然生效，触发拦截时服务端不会主动回传错误信息，就会一直保持等待状态）
     • 服务端正在执行仓库钩子校验（大文件扫描、CI触发、权限校验），因为上传的包体积过大，校验耗时远超出预期，看起来像流程卡住
     • 网络链路存在丢包：本地显示上传完成的27M内容，实际服务端没有接收完整，TCP层静默重传时不会在Git界面输出进度，就会卡在最后阶段

• 第一步先确认卡住的真实节点：按Ctrl+C终止当前push进程，加上包追踪参数重新执行GIT_TRACE_PACKET=1 git push 远程名 分支名
  • 如果追踪日志一直显示等待服务端回包，说明是服务端侧处理卡点，优先排查打包内容里的历史大文件
  • 如果追踪日志显示本地在反复重传数据包，说明是网络链路丢包，切换网络环境重新尝试推送
• 第二步定位待上传的大文件来源：执行git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | sed -n 's/^blob //p' | sort --numeric-sort --key=2 | tail -n 10，列出本地仓库内体积最大的10个Git对象，如果存在和本次修改无关的超大文件，将这类文件从Git历史中清理后再推送
• 第三步规避服务端拦截问题：不要把本地积累的所有历史提交一次性推送到远程，拆分批次推送，先推送本次的单文件修改，避开GitLab的单包大小限制
• 关于你之前的配置说明：
  • 首先你之前执行配置命令时，使用的是全角长破折号–而非Git命令要求的半角双破折号--，这两条配置实际根本没有写入到Git配置文件中，完全不生效
  • 就算你把破折号改对，关闭sendpack.sideband的操作也是反向加剧了卡住的体感——这个参数的作用是控制Git服务端是否将实时处理进度回传给本地，关闭后你本来就不会看到服务端的处理输出，自然会觉得流程卡死
  • 调整http.postBuffer仅能控制本地HTTP请求的缓冲区大小，无法解决服务端拦截、历史大文件、网络丢包类问题，对当前场景没有实际作用

内容的提问来源于stack exchange，提问作者余昌翰