fatal: protocol error: bad pack header

时间:2025-05-13 08:19:25
问题描述:

某次在拉取大仓库(2.2G)时,报错如下

[root@localhost ~]# git clone /xxx/bbb_ios.git
正克隆到 'bbb_ios'...
Username for '': ccc
Password for 'http://ccc@':
remote: Counting objects: 26216, done.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

经过大量资料查询,其中给到一种原因及解决方法是这样的:
发生这个问题一般是项目中某些资源太大导致,可以尝试ssh方式clone ,或者解决方式如下

首次clone的层数定位在第一层
#git  clone 仓库地址 --depth 1

然后cd到项目目录中
#cd 项目目录

在此下拉内部文件,--unshallow 即不使用浅克隆
#git fetch --unshallow
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

然而这样操作完之后,有两个问题:

  • 得到的代码不全的
  • 执行git fetch --unshallow依然会报同样的错

然后有人又给到解决方案,继续实践:

git config --global  “200m”
git config --global  “200m”
git config --global  1
git  clone 仓库地址 --depth 1
  • 1
  • 2
  • 3
  • 4

结果报错依然如故

查看拉取机器的内存,发现还有几百兆的剩余内存,此时还不敢确定是否就是拉取机器的内存不足导致的。然后去到官网,查到一段很有用的信息,如下:

This usually happens because some kind of process monitor has killed the git pack-objects process due to excessive memory usage.

If you are on a shared machine, you need to talk to the host about memory limits. If you run the machine yourself, you should probably already know what to look for.

How big is the repository you are trying to clone, and how much memory does your server have? We had a similar problem with a 150mb repository on a heavily loaded server with only 3.5 GB of RAM. We moved to 8 GB of RAM, and haven’t had the problem since.
  • 1
  • 2
  • 3
  • 4
  • 5

然后果断的升级拉取机器的内存,问题最终得以解决。