当我试图逃跑的时候

git push origin master --force

我刚刚

Counting objects: 2649, done.
Delta compression uses 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

这和缺乏安全感有关吗?我尝试创建一个公钥作为致命的答案:远程端意外挂断并重新运行它,但它仍然不工作。我不是在用钥匙吗?如果是,我该如何使用它?


当前回答

如果您正在使用windows版本的git(如果您在windows机器上执行此操作,则很可能是这样),并且这里的其他修复都不适合您,请尝试访问https://github.com/git-for-windows/git/releases,获取2.4.5版本或之后的版本。帮我搞定了。

其他回答

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

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

git config http.postBuffer 524288000

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

对我们来说,问题是我们有大量的文件应该由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

如果在存储库上缺少写权限,也可能引发此错误。


我的具体案例是这样的:

我用服务器的根用户(通过SSH)创建了一个repo。 我安装了一个git服务,并创建了一个git linux用户,该用户应该管理所有与git相关的操作。 到那时,我已经忘记了这个repo最初是由根用户创建的,而git用户根本没有向存储库中写入任何内容的文件权限。

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

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

我能够使用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"