Question

我在OSX上使用SourceTree并使用Git推送到Visual Studio Online。我收到以下错误：

POST git-receive-pack（490857233字节）
      错误：RPC失败; result = 22，HTTP代码= 404
      致命：远程端意外挂断了       一切都是最新的       完成但有错误，见上文

我已经尝试了以下内容：

git config --global http.postBuffer 524288000

Answer 1

我遇到了一个非常类似的错误（这个答案是谷歌的最佳结果） - 解决方案是@Liviu Chircu的评论

解决方案是将.git放在网址的末尾

git clone http://myURL/projectname
Cloning into 'projectname'...
error: RPC failed; result=22, HTTP code = 404
fatal: The remote end hung up unexpectedly

然而：

git clone http://myURL/projectname.git

成功。

奇怪的是，没有.git的原始URL在两台Linux机器和一台Windows桌面上成功，但在第三台Linux机器上失败了。包括.git使其适用于所有计算机。

Answer 2

您的存储库可能很大，尝试以块的形式上传，例如使用GIT在历史记录中途恢复到新分支的一半，推送它，然后推送最新的提交。

可能是一个更好的解决方法，但这是我能够快速解决我的问题

我能够推动108.61 MiB，但不是144.64 MiB

希望这有帮助。

Answer 3

2016年6月更新：根据this page：

对Team Services的SSH身份验证Git repos目前处于私有预览状态

我建议您切换到SSH身份验证，如果能够，因为这应该完全避免这个问题。（请注意，您可以串联使用HTTPS和SSH，even on the same machine。）

如果尚未启用此功能，或者您无法切换到SSH，请继续阅读。

原帖：

正如@Oxymoron所提到的那样，问题在于您的存储库太大了，或者更具体地说，您是在尝试过多地推送存储库。

什么？这没有意义！这不是HTTP 404代码的用途！

对我来说也没有意义。 *强调微软的总体方向*

您可能已遇到此问题并收到如下错误：

Unable to rewind rpc post data - try increasing http.postBuffer

这很可能导致你执行你提到的git config命令。

现在我的发布单独答案：我想扩展你如何解决这个问题。您仍然会尝试一次推送一组较小的提交，但这并不像听起来那么容易。这是过程：

确定一次推送的提交数量。我通常建议使用二进制搜索来确定你可以推送多少，但由于推送之间的等待时间，这可能很困难。此外，许多repos具有非常大的第一次提交，或者之后的某些提交非常大。如果您知道此类提交，请尝试自行推送。如果您的仓库足够小，那么一次只推送一个提交可能最简单。否则，尝试推送20-30次提交，如果遇到问题则减少数量。
假设您有一个分支master，请在同一位置创建一个新分支，例如master-temp。
将master重置为您要推送的第一个组中的最后一次提交。例如。 git reset --hard master-temp~100。
推送该提交（git push）。
在下一组的最后一次提交时进行--ff合并。（git merge --ff-only master-temp~90）
重复步骤4和5，直到所有提交都被推送。

举个例子，考虑一下这个回购：

$ git log --oneline --decorate
* fffffff (HEAD -> master) Commit six
* eeeeeee Commit five
* ddddddd Commit four
* ccccccc Commit three
* bbbbbbb Commit two
* aaaaaaa Commit one

这就是你要做的，假设你想一次推送一个提交：

$ git checkout -b master-temp master
$ git checkout master
$ git reset --hard aaaaaaa
$ git push origin master
$ git merge --ff-only bbbbbbb
$ git push origin master
$ git merge --ff-only ccccccc
$ git push origin master
$ git merge --ff-only ddddddd
$ git push origin master
$ git merge --ff-only eeeeeee
$ git push origin master
$ git merge --ff-only fffffff
$ git push origin master

理想情况下，这样做很好，而且你已经完成了。但是，如果无法推送给定的提交，即使这是您推送的唯一提交，会发生什么？首先，尝试再推一次或两次;似乎在推动失败所需的程度上存在一些不一致。

如果仍然没有推动，那么现在是重写历史的时候了。

但我不想改写我的历史！我的Git日志很干净，因为我花了很多时间学习如何write great commit messages，而且我总是keep my commits atomic。

返回（更新）示例repo：

* fffffff (HEAD -> master) Tiny commit five
* eeeeeee Tiny commit four
* ddddddd Tiny commit three
* ccccccc Tiny commit two
* bbbbbbb Tiny commit one
* aaaaaaa This commit is massive

（大规模提交可以在任何地方，也可以有多个。）

一般的想法是，您对split the massive commit into a few smaller ones进行了交互式变基（git rebase -i）。

$ git checkout -b master-temp master
$ git rebase -i --root

注意：只有在需要拆分第一次提交时才需要--root。否则，例如git rebase -i bbbbbbb。

将要从pick拆分的提交更改为edit。

$ git reset HEAD^
$ git add somefiles
$ git commit
$ git push origin master-temp
$ git add someotherfiles
$ git commit
$ git push origin master-temp
$ git rebase --continue
$ git push origin master-temp

现在这是 ~~magit~~ 魔法发生的地方：

$ git checkout master
switched to branch 'master'
$ git push origin master
POST git-receive-packed (chunked)
remote: Analyzing objects... (1212/1212) (2518523 ms)
remote: Storing packfile... done (48186 ms)
remote: Storing index... done (228 ms)
Pushing to https://example.visualstudio.com/SomeCollection/SomeTeam/_git/MyRepo
To https://example.visualstudio.com/SomeCollection/SomeTeam/_git/MyRepo
 * [new branch]    master -> master
updating local tracking ref 'refs/remotes/origin/master'

最后一个命令会成功，因为Git足够聪明，可以重复使用已推送的项目，即使它们处于不同的提交。（请注意，Analyzing objects步骤是花费时间最长的步骤。这是Git计算可以重复使用的数量，以及需要上传的数量。）如果您有兴趣了解有关其工作原理的更多信息，请检查可能是在Packfiles section of the Git Internals docs上刷完后Git Objects。

我是否提到过Git很棒？

Answer 4

“奇怪的是，没有.git的原始URL在两台Linux计算机和Windows桌面上都成功，但是在第三台Linux计算机上却失败了。包括.git使其可以在所有计算机上使用。”

可能是git版本太旧

Answer 5

克隆时，我刚刚在git URL的末尾添加了.git。

Git错误：RPC失败;结果= 22，HTTP代码= 404

5 个答案: