git - Git，致命：远程端意外挂断

Question

当我试图跑

git push origin master --force

我刚得到

Counting objects: 2649, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1280/1280), done.
error: RPC failed; result=22, HTTP code = 413 | 116 KiB/s   
fatal: The remote end hung up unexpectedly
Writing objects: 100% (2504/2504), 449.61 MiB | 4.19 MiB/s, done.
Total 2504 (delta 1309), reused 2242 (delta 1216)
fatal: The remote end hung up unexpectedly
Everything up-to-date

是否与不安全有关？我尝试按照致命的答案创建一个公钥：远程端意外挂断并再次运行它，但它仍然无法正常工作。我实际上没有使用密钥吗？如果是这样，我该如何使用它？

score 685 · Accepted Answer

问题是由于 git/https 缓冲区设置造成的。为了解决它（从Git 推送提交到 github 时失败）

git config http.postBuffer 524288000

并再次运行命令

score 111 · Accepted Answer

原因：已超出 Git 的默认文件发布大小。

解决方案：

导航到回购。

导航到存储库后，运行以下命令将缓冲区增加到 500MB：

git config http.postBuffer 524288000

score 110 · Accepted Answer

这看起来类似于How do I get github to default to ssh 而不是 https for new repositories。可能值得尝试从 http 协议切换到 ssh：

$ git remote add origin git@github.com:username/project.git

score 49 · Accepted Answer

你可能会收到这样的错误

错误：无法锁定配置文件 .git/config：没有这样的文件或目录

那是因为你没有本地.git/config文件你可以通过这个命令让它工作：

git config --global http.postBuffer 524288000

score 37 · Accepted Answer

其他解决方案在我的情况下不起作用，进行垃圾收集为我修复了它：

git gc --aggressive

你可以git gc先试试。

score 29 · Accepted Answer

罪魁祸首（以我为例）：
高延迟网络。

这本身不是一个答案，而是更多可能对其他人有所帮助的观察。我发现这个错误偶尔会在高延迟网络上弹出（例如，我必须使用卫星天线来访问互联网）。网络速度很好，但延迟可能很高。注意：该问题仅存在于某些场景中，但我尚未确定模式是什么。

临时缓解措施：
我切换了网络——我搬到了一个速度较慢但延迟更低的蜂窝网络（我的手机用作热点）——问题就消失了。请注意，我只能间歇性地执行此操作，因为我的单元连接也是间歇性的。加上带宽使用增加了成本。我也很幸运，我有这个选项可供我使用。不是每个人都这样做。

我确信某处有一些配置设置使 git（或 ssh 或 curl 或任何超时时间）更能容忍此类网络，但我不知道它是什么。

对开发商的恳求：
这类问题一直是农村人口面临的问题。当您设计系统、工具和应用程序时，请考虑我们。谢谢你。

score 20 · Accepted Answer

与其他答案之一相反 - 我在使用 ssh 推送时遇到问题 - 我切换到 https 并且它已修复。

git remote remove origin
git remote add origin https://github.com/user/repo
git push --set-upstream origin master

score 12 · Accepted Answer

如果使用 GitHub，在 repo 的目录中，运行此命令以设置http.postBuffer为 GitHub 的最大允许值：

git config http.postBuffer 2147483648

如果使用克隆 repo git clone，则可以使用相同的选项克隆它：

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 记录的错误：

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

score 10 · Accepted Answer

基于您用来推送到您的存储库的协议

HTTP

git config --global http.postBuffer 157286400

参考：

https://git-scm.com/docs/git-config#Documentation/git-config.txt-httppostBuffer

SSH

~/.ssh/config在您的 linux 机器中的文件中添加以下内容

Host your-gitlab-server.com
  ServerAliveInterval 60
  ServerAliveCountMax 5
  IPQoS throughput

参考：

score 9 · Accepted Answer

此错误也可能因缺少对存储库的写入权限而引发。

我的具体案例是这样的：

我用我的服务器用户创建了一个仓库root（通过 SSH）。
我安装了一个 git 服务并创建了一个gitlinux 用户来管理所有与 git 相关的操作。
到那时，我已经忘记了 repo 最初是与root用户一起创建的，而git用户根本没有文件权限来向存储库中写入任何内容。

score 8 · Accepted Answer

这篇文章有很好的解释，它解决了我的问题。

git config --global http.postBuffer 157286400

https://confluence.atlassian.com/stashkb/git-push-fails-fatal-the-remote-end-hung-up-unexpectedly-282988530.html

score 7 · Accepted Answer

以下命令可能会帮助您...

git config --global http.postBuffer 1048576000
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999

score 5 · Accepted Answer

在我们的例子中，问题是一个克隆写了一个.git/config文件，其中包含一个只读访问方法的 url 条目。将 url 从://方法更改为@方法解决了问题。

运行git remote -v说明了一些问题。

score 5 · Accepted Answer

即使在配置后缓冲区后，问题也没有解决。

当我将 wifi 网络从宽带更改为移动热点时，我的问题得到了解决。这可能不是逻辑上正确的答案，但它解决了问题。

确保您有良好的互联网速度。

score 4 · Accepted Answer

上述解决方案都不适合我，但是我推动的提交非常大。

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

score 3 · Accepted Answer

如果您正在使用 git for windows（如果您在 windows 机器上执行此操作，您很可能是这样），并且此处的其他修复都不适用于您，请尝试转到https://github.com/git-for- windows/git/releases，并获得 2.4.5 或之后的版本。为我修好了。

score 3 · Accepted Answer

您可能确实在现有的存储库中克隆了存储库，要解决此问题，只需将存储库克隆到另一个目录并将更改复制到这个新目录，然后运行推送。

score 3 · Accepted Answer

另一个补充，因为我以不同的方式遇到了这个错误，谷歌把我带到了这里。

我的问题是大小写不匹配；一个camelCase，一个没有。显然，GIT 在不告诉你原因的情况下阻止你这样做。因此，如果您的分支仅在大小写上与远程分支不同，请尝试将它们更改为相同。

请参阅： Git：合并后的“主无法解析为分支”

score 3 · Accepted Answer

这可能在更新您的 OSX 平台后发生。

打开终端并导航到您的 .ssh 文件夹，然后输入ssh-add -K ~/.ssh/id_rsa

score 3 · Accepted Answer

就我而言，在使用 Intellij Idea 进行推送时出现此错误。

这是我追踪错误并修复它的方法。

在终端中启用调试日志记录，这绝不是一个坏主意:)

set GIT_CURL_VERBOSE=1 set GIT_TRACE=1

通过终端推送，而不是通过 intellij

git push 
-> fatal: The current branch feature/my-new-feature has no upstream branch.
To push the current branch and set the remote as upstream

解决方案是设置上游，之前肯定出错了：

git push --set-upstream origin feature/my-new-feature

score 3 · Accepted Answer

最近我遇到了同样的问题。克隆远程存储库时，出现如下错误：

致命：远端意外挂断 MiB | 7.00 KiB/s
致命：早期 EOF
索引包失败

当我用谷歌搜索错误时，我被重定向到这里。我遵循了大多数答案，但没有解决我的问题。

唯一的解决方案是重新安装我的“网络适配器 (WiFi) 驱动程序软件”。因此，我要强调的是，上述错误也可能是您 PC 的 WiFi 驱动程序软件中的问题引起的。如果上述答案都不起作用，那么您可以尝试重新安装 WiFi 驱动程序。它将解决问题。

您可以轻松地重新安装 WiFi 驱动程序，如下所示：

打开网络和互联网设置
选择“网络重置”
然后选择“立即重置”

重启电脑后，尝试 git 操作成功（推/拉/克隆）。

score 2 · Accepted Answer

PLESK Nginx 和 GIT 我在 plesk git 上遇到了这个错误，在使用（谁知道是什么）推送一个大型 repo 时，它给了我这个 HTTP 代码 413 的错误，我查看了以下服务器是 Plesk，它运行了 nginx 和 apache2所以我查看了日志并在 nginx 日志中发现了错误

按照此链接允许 plesk 使用更大的文件上传来重建配置。

我跳过了 git 的 php 部分

之后 git push 工作没有任何错误。

score 2 · Accepted Answer

以上答案都不适合我，但这就是有效的。

.git/从您的项目中删除
将远程仓库克隆到某个新位置，例如您的桌面：
```
git clone https://github.com/foo/bar.git
```
.git/从新位置移动到旧位置
重新提交并推送您的更改

score 2 · Accepted Answer

我通过重新包装解决了这个问题：

git repack --max-pack-size=100M -a -d

转到存储库 > 在 GitHub Desktop 的命令提示符中打开运行以下命令：

set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
git push origin <branch>

score 1 · Accepted Answer

我碰巧在拉动时遇到了同样的错误。
我已经完成了“http.postBuffer”技巧。它解决了它，但是当我想推送时，我又遇到了错误。

是什么解决了我的问题：
1. 将它克隆到另一个带有其他虚拟机的文件夹中。（Linux）。
2. 我已经完成了我的更改。
3. 用我一开始不能推送的原始虚拟机推送。（视窗）

score 1 · Accepted Answer

我也有同样的问题。我从 git 网页注意到 SSH 克隆 URL 具有以下结构：

git@github.com:user/project.git

我只需将“：”更改为“/”即可解决我的问题，如下所示：

git@github.com/user/project.git

可能这会有所帮助。

score 1 · Accepted Answer

添加答案似乎几乎毫无意义，但是当我终于发现它是 Visual Studio Online 正在遭受零星中断时，我已经为此奋斗了很长时间。当 VS 不断提示输入信用并且 VSO 网站有时给出 500 时，这一点变得很明显。

Counting objects: 138816, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (38049/38049), done.
error: unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
The remote end hung up unexpectedly/138816), 33.30 MiB | 3.00 KiB/s
Writing objects: 100% (138816/138816), 50.21 MiB | 3.00 KiB/s, done.
Total 138816 (delta 100197), reused 134574 (delta 96515)
fatal: The remote end hung up unexpectedly
Everything up-to-date

之后我将我的 HTTP 发布缓冲区设置回 2 MB，因为我实际上认为它适用于许多较小的帖子。

score 1 · Accepted Answer

似乎它可以是一千件事中的一件。

对我来说，我最初是通过 SourceTree 推动 master 和 development（master 没有变化）。将其更改为开发仅有效。

score 1 · Accepted Answer

我在上传大型 repo 时遇到了类似的错误，“致命：远程端意外挂断”，没有任何进一步的细节。

经过大量研究，这就是我所做的：

使用 SSH 而不是 HTTPS，并没有解决问题。
将 http.postBuffer 增量增加到一个非常大的值，仍然没有运气。
我发现这可能是因为 repo 中的文件很大（因为这是从 perforce 新迁移的 repo），所以我使用 LFS 重新创建了 repo，将 largeFileThreshold 设置为 40m，这大大减少了 repo 大小（从 3.5G 到500M）。我认为这会解决问题，但令我惊讶的是，我仍然面临同样的错误。

最后，我想到可能是我使用的是较旧的 git 客户端，因为我没有看到其他错误消息。我将 git 客户端升级到最新（2.20.1），瞧，错误消失了！

score 1 · Accepted Answer

1

我也遇到了这个错误。一秒钟git push就成功了

于 2021-12-02T13:54:13.473 回答

score 1 · Accepted Answer

对我们来说，问题是我们有大量文件应该由git lfs管理。

我们采取了以下措施来解决问题：

# Soft reset so you can author a new commit
git reset --soft HEAD~1

# Install git lfs
git lfs install

# Track large files of a specified file type YMMV
git lfs track "*.uasset" "*.umap"

# Re-add everything
git add .

# Author a new commit
git commit -m "git lfs ftw"

# Push
git push

score 0 · Accepted Answer

当我在 .ssh 中的密钥对不正确时出现此错误。将 pubkey 添加到 github（在设置中）为我解决了这个问题。

score 0 · Accepted Answer

执行此操作以查看您正在使用的密钥：

ssh -vT git@github.digitalglobe.com

然后确保在您的构建中一开始就运行此命令：

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

score 0 · Accepted Answer

1) cd 到项目目录

2)git status

3)git checkout -f HEAD

4) 通过再次拉下 master 来确认成功，以确保如果您的 repo 看起来不完整，您是最新的

如果您在从 Bitbucket 克隆存储库时从 Visual Studio 的 Git 中收到有问题的错误，则此方法有效

score 0 · Accepted Answer

如果您推送的任何提交格式不正确，也会发生这种情况。

我（在不知不觉中）提交了一个格式错误的作者电子邮件字段，但我得到的只是这个模糊的remote end hung up错误消息。我能够推送其他分支而不是这个分支，所以我开始一次推送一个来自“坏”分支的提交，直到我最终登陆：

Pushing to git@github.com:directangular/unicorn.git
Counting objects: 100% (9/9), done.
Delta compression using up to 20 threads
Writing objects: 100% (5/5), 549 bytes | 549.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: error: object 74c7584ff0b93591c19d3a3c19695889dd2274d2: badEmail: invalid author/committer line - bad email        
remote: fatal: fsck error in packed object        
error: remote unpack failed: index-pack abnormal exit
To github.com:directangular/unicorn.git
 ! [remote rejected]       pizzafeast -> pizzafeast (failed)
error: failed to push some refs to 'git@github.com:directangular/unicorn.git'

所以看起来这个remote end hung up unexpectedly错误有点“吞下”实际的错误信息，这可能是我在这里遇到的某种格式错误的提交。

修复格式错误的电子邮件后，我能够很好地推送。

score 0 · Accepted Answer

我认为这样做不是一个好主意，但是如果您在您的机器中有备份..再推一次，然后尝试克隆 repo，然后从旧目录中删除 .git 并从新克隆的文件夹中移动 .git .. git 已解决但由于这个问题，一些文件可能无法在 git 上传。再次从您的备份中推送所有内容，然后将其拉到您的服务器或另一台机器上，使其损坏。现在我只是这样做了...对我有用..并在执行此操作之前备份您的目录。

如果我错了，请纠正我。我也不知道这样做后会出现什么问题？但这一次真的奏效了。

score 0 · Accepted Answer

我的问题（致命：远程端意外挂断）已通过检查存储库权限和所有者解决。

git 存储库文件所有者必须是您想要使用它推送/拉取/克隆的用户。

score 0 · Accepted Answer

我的问题原因是网络设置：我有一个“杀手”wifi 卡，它显然会以 SSH 和 SSL 不喜欢的方式处理网络数据包。

为了解决这个问题，我不得不进入“Killer Control Center”、“Parameters”，并禁用“Advanced Stream Detect”——git 命令立即重新开始工作。

score 0 · Accepted Answer

有同样的问题并尝试所有答案都不起作用，只需尝试另一个帐户，这对我有用。

score 0 · Accepted Answer

对我来说，当我试图从一个甚至不存在的分支中提取时，我得到了同样的错误。

因此，请在拉动时检查分支名称。

score 0 · Accepted Answer

0

从bashvscode 上的 shell 切换到zsh为我修复它。

于 2021-04-10T15:12:53.553 回答

score 0 · Accepted Answer

在我的情况下，这个错误是因为 VPN 连接中断。只需关闭并打开 VPN 即可修复错误。

score -1 · Accepted Answer

我能够使用 Git Shell 解决这个问题。

github.com 中的每个存储库都为您提供 HTTPS/SSH/Subversion URL，您可以使用它们通过 Shell 下载，请参见此处： http: //prntscr.com/8ydguv。
根据 GitHub 最近的变化，SSH 似乎是最好的方法。

在 Shell 中使用的命令：

git clone "URL of repo goes here w/ no quotes"

score -1 · Accepted Answer

-1

当我拼错远程分支名称时出现此错误

于 2016-03-16T13:54:46.337 回答

git - Git，致命：远程端意外挂断

44 回答 44

为什么是这个值？

为什么不设低点？

为什么不设置更高？

Related

Reference