我找到了一个适合我的解决方案Here。
在.git/config文件（客户端和/或服务器端）中，我添加了以下内容：

[core]
  packedGitLimit = 128m
  packedGitWindowSize = 128m

[pack]
  deltaCacheSize = 128m
  packSizeLimit = 128m
  windowMemory = 128m

字符串

作为参考（您可能已经看到了），处理该问题的msysgit案例是ticket 292。
它提出了几种解决方法：

• 全局禁用增量压缩。为此，您必须set pack.window to 0。当然，这将使存储库在磁盘上更大。
• 对某些文件禁用增量压缩。检查manpage to gitattributes上的delta标志。
• git config --global pack.threads 1个
• git config --global pack.windowMemory 256m（您已经尝试过了，但也在“Error when pulling warning: suboptimal pack - out of memory“中进行了说明）
• 其他设置在“git push fatal：unable to create thread：Resource temporarily unavailable”和“Git pull fails with bad pack header error“中提到，以防这与pack相关。
• sm4在评论中添加：

要在.git/info/attributes中禁用某些文件的增量压缩，请添加：

*.zip binary -delta

字符串
关于Gitattributes man page：
对于属性delta设置为false的路径，将不会对blob尝试增量压缩。
也许一个更简单的解决方法是在大文件提交之前重置历史记录，然后从那里重做其他提交。

编辑：自git-v2.5.0（2015年8月）起，git-for-windows（原MSysGit） 

   提供64-bits versions，正如Pan.student所注意到的。
   在这个回答中，我建议使用install Cygwin 64位（提供64位Git版本）。
我在使用MSysGit达到4GB屏障时遇到了类似的Out of memory, malloc failed问题：

> git --version
git version 1.8.3.msysgit.0

> file path/Git/cmd/git
path/Git/cmd/git: PE32 executable for MS Windows (console) Intel 80386 32-bit

> time git clone --bare -v ssh://linuxhost/path/repo.git
Cloning into bare repository 'repo.git'...
remote: Counting objects: 1664490, done.
remote: Compressing objects: 100% (384843/384843), done.
remote: Total 1664490 (delta 1029586), reused 1664490 (delta 1029586)
Receiving objects: 100% (1664490/1664490), 550.96 MiB | 1.55 MiB/s, done.
Resolving deltas: 100% (1029586/1029586), done.
fatal: Out of memory, malloc failed (tried to allocate 4691583 bytes)
fatal: remote did not send all necessary objects

real    13m8.901s
user    0m0.000s
sys     0m0.015s

字符串

的数据
最后git 64 bits从Cygwin修复它：

> git --version
git version 1.7.9

> file /usr/bin/git
/usr/bin/git: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows

> time git clone --bare -v ssh://linuxhost/path/repo.git
Cloning into bare repository 'repo.git'...
remote: Counting objects: 1664490, done.
remote: Compressing objects: 100% (384843/384843), done.
remote: Total 1664490 (delta 1029586), reused 1664490 (delta 1029586)
Receiving objects: 100% (1664490/1664490), 550.96 MiB | 9.19 MiB/s, done.
Resolving deltas: 100% (1029586/1029586), done.

real    13m9.451s
user    3m2.488s
sys     3m53.234s

型

的
仅供参考，linuxhost 64位：

repo.git> git config -l
[email protected]
core.repositoryformatversion=0
core.filemode=true
core.bare=true

repo.git> git --version
git version 1.8.3.4

repo.git> uname -a
Linux linuxhost 2.6.32-279.19.1.el6.x86_64 #1 SMP Sat Nov 24 14:35:28 EST 2012 x86_64 x86_64 x86_64 GNU/Linux

型
如果我的回答不能解决您的问题，您也可以查看这些页面：

• git clone out of memory even with 5.6GB RAM free and 50 GB hard disk
• Git clone fails with out of memory error - “fatal: out of memory, malloc failed (tried to allocate 905574791 bytes) / fatal: index-pack failed”
• git-clone memory allocation error
• MSysGit issues tracker

在选定的答复中提出的一些选择似乎只是部分地与问题有关，或者根本没有必要。
从https://git-scm.com/docs/git-config来看，似乎只需设置以下选项就足够了（仅为此处的项目设置）：

git config pack.windowMemory 512m

字符串
从手册：
pack.windowMemory
git-pack-objects[1]中的每个线程在命令行上没有给出限制的情况下，对于打包窗口内存所消耗的最大内存大小。该值可以后缀为“k”，“m”或“g”。如果不进行配置（或显式设置为0），则没有限制。
有了这个，我从来没有超过指定的512 m * 每线程 *，实际使用的RAM大约是一半的时间。当然，这里选择的数量是用户特定的，取决于可用的RAM和线程数。

我在Ubuntu上遇到了这个错误消息。在我的情况下，一个大的提交文件引起了问题。我意识到这个问题是由于一个文件，我没有注意到最初。
识别大文件：
要在Git历史记录中识别大文件，可以使用以下命令：

git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | sed -n 's/^blob //p' | sort --numeric-sort --key=2 | cut -c 1-12,41- | $(command -v gnumfmt || echo numfmt) --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest

字符串
此命令列出Git历史记录中的对象，按大小排序，并以人类可读的格式显示文件大小。
来源：How to find/identify large commits in Git history
删除大文件：
一旦识别出这个大文件，你就可以使用以下命令从Git历史中删除它：

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch path/to/my/file.jpg' --prune-empty --tag-name-filter cat -- --all

型
此命令筛选分支历史记录并删除指定的文件。
来源：Removing large files from Git history
Update .gitignore：
之后，请确保删除该文件或将其添加到.gitignore：

echo 'path/to/my/*' >> .gitignore

型
请记住添加、提交和推送更改，以在远程存储库中反映它们。
希望这能有所帮助。

在我的情况下，上面的配置更改没有帮助。有帮助的是一个简单的服务器重新启动（在我的情况下sudo shutdown -r now）。看起来像是有什么东西在服务器上占用了大量内存。希望这也能帮助到别人。

这对我来说很有效，但我必须通过命令行设置选项：

git --global core\pack [param] value

字符串