以上的解决方案都不适合我，但是我要提交的任务非常大。

非常简单，我把它分成两个提交，分别推送每个提交，它立即通过。

这是由于git/https缓冲区设置。

运行这个(从Git中获取的文件在提交到github时失败):

git config http.postBuffer 524288000

然后，再次运行原来的命令。

对我来说，问题的原因是网络设置:我有一个“杀手”wifi卡，它显然会以一种SSH和SSL不喜欢的方式破坏网络数据包。

为了解决这个问题，我不得不进入“杀手控制中心”，“参数”，并禁用“高级流检测”- git命令立即重新开始工作。

如果使用GitHub，在repo目录下，运行此命令设置http。postBuffer似乎是它的最大允许值GitHub:

git config http.postBuffer 2147483648

如果使用git clone克隆一个repo，可以使用相同的选项克隆它:

git clone -c http.postBuffer=2147483648 git@github.com:myuser/myrepo.git /path/to/myrepo

在这两种情况下，上述数字都相当于2 GiB。然而，您可能需要达到这个数量的空闲内存才能使用这个值。

确保每次推送到GitHub都提交不超过这个大小的更改。事实上，为了安全起见，我会将提交推的大小保持在1.8 GiB以下。这可能需要将一个较大的提交划分为较小的提交和推送。

为什么是这个值?

之所以使用这个特定的值，是因为至少在2018年，这个值被记录为GitHub的推送大小限制:

我们不允许超过2GB的推送

为什么不放低一点呢?

一些先前的答案说将其设置为524288000 (500 MiB)，但这个数字似乎是任意的，没有价值。任何较低的值都可以工作，只要您的推送大小不大于设置的值。

为什么不设高一点呢?

如果你将这个值设置为高于2 GiB，并且如果你尝试的推送大小也更高，你可以期待GitHub的文档错误:

远程:致命:包超过允许的最大大小

我在上传一个大型回购时也遇到过类似的错误，“致命:远程端意外挂起”，没有任何进一步的细节。

在做了大量研究之后，我是这样做的:

使用SSH代替HTTPS并不能解决问题。 增加http。postBuffer增量到一个很大的值，仍然是no 运气。 我想这可能是因为大文件在 回购(因为这是从perforce新迁移的回购)，所以我使用LFS重新创建了回购，将largeFileThreshold设置为40m，这大大降低了回购大小(从3.5G到500M)。 我原以为这样就能解决问题，但令我吃惊的是，我还是犯了同样的错误。

最后，我突然想到，我可能正在使用一个旧的git客户端，因为我没有看到额外的错误消息。 我把git客户端升级到最新版(2.20.1)，瞧，错误消失了!

我不认为这是一个好主意，但如果你有备份在你的机器..再推一次，然后尝试克隆repo，然后从旧目录中删除.git，并从新的克隆文件夹中移动.git。Git已解决，但由于这个问题，一些文件可能无法在Git上上传。再次从你的备份，然后把它拉到你的服务器或其他机器，它得到curcurt。现在我刚做了这个…对我有用。在这样做之前，备份一下你的文件夹。

如果我说错了，请指正。我也不知道这样做之后会出什么问题?但这次真的管用了。