对于我来说，我使用git子模块，通过以下方法解决:

git fetch 

然后在开发的分支上创建任何提交。

git push origin develop
git pull origin develop 

如果您推送的任何提交都是畸形的，也会发生这种情况。

我(不知不觉中)提交了一个畸形的作者电子邮件字段，但我得到的只是这个模糊的远程挂断错误消息。我能够推送其他分支，而不是这个分支，所以我开始推送来自“坏”分支的提交，直到我最终降落在:

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'

因此，看起来远程端意外挂起的错误有点像“吞下”实际的错误消息，这可能是我在这里看到的某种畸形提交。

在修复了错误的电子邮件后，我能够很好地推动。

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

运行git remote -v可以解释这个问题。

其他解决方案在我的情况下不起作用，做垃圾收集为我解决了这个问题:

git gc --aggressive

你可以先试试git gc。

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

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

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

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

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

因此，请在您执行操作时检查分支名称。