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

Question

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

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

我已经尝试过以下方法：

git config --global http.postBuffer 524288000

- guinzu

---

HTTP 404表示“文件未找到”，表示您的URL有误。您可以发布您试图推送的URL吗？您能发布VSO的屏幕截图，并扩展“克隆URL”选项卡吗？ - Edward Thomson

你可能会这样想，但如果你清除缓冲区覆盖，404错误就会消失，而你只会得到一个普通的挂起错误。 - Chris Woolum

由于错误的 git URL：https://.../foo 而不是 https://.../foo.git，我遇到了类似的错误。 - Liviu Chircu

可能是RPC失败结果22 HTTP代码404的重复问题。 - jdhao

GitLab上报告了这个bug：https://gitlab.com/gitlab-org/gitlab/issues/29629 --- 解决方法是添加“.git”后缀。 - sorin

Answer 1

我遇到了一个非常类似的错误（这个答案是谷歌搜索结果中排名最高的），解决方法是由@Liviu Chircu在评论中提供的。

解决方法是在URL末尾添加.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

成功了。

奇怪的是，在两台Linux机器和一台Windows桌面上，没有.git的原始URL都成功了，但在第三台Linux机器上失败了。包含.git可以让它在所有的机器上工作。

- user2711915

---

这个答案解决了我的问题。git config --global http.postBuffer 524288000 不起作用。 - jdhao

对我来说也是一样的问题，在 Gitlab 11.11.5-ee 服务器上。添加 .git 后问题得以解决。 - Andrey Regentov

我在CentOS 7上遇到了这个问题。在URL末尾添加.git解决了我的问题。 - shogitai

这个可行！应该是被接受的解决方案。谢谢。 - krinker

有没有想过为什么使用 .git 可以正常工作，而不带 .git 时克隆有时会失败？ - Mustafa Mahmod

Answer 2

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

- Sai Ram Regunta

---

没有比之前的顶部和被接受的答案更多的内容。 - ZzZombo

Answer 3

您的仓库可能太大了，尝试分块上传，例如使用GIT在历史记录中回滚一半或者更多，在新分支上推送它，然后再推送最新的提交。

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

我能够推送108.61 MiB，但无法推送144.64 MiB。

希望这可以帮到您。

- Oxymoron

---

我在一个小仓库中遇到了同样的问题。 - John

Answer 4

2016年6月更新：根据this page的说法：

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

如果您能够使用SSH身份验证，我建议您切换到该方式，因为这应该可以完全避免这个问题。（请注意，您可以在同一台机器上同时使用HTTPS和SSH，即使如此。）

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

---

原始帖子：

正如@Oxymoron所述，问题在于您的存储库太大，或者更具体地说，您正在尝试一次推送过多内容。

什么？那不合理！这不是HTTP 404代码的作用！

对我来说也没有意义。*瞪着微软的方向*

您可能已经遇到了这个问题，并收到了类似以下错误消息：

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

“这可能是导致你执行了你提到的`git config`命令的原因。”

“现在，为了发布一个单独的答案：我想扩展一下如何解决这个问题。你仍然会尝试一次推送较小的提交集合，但这并不总是那么容易。以下是该过程：”

1. 确定每次推送多少个提交。通常建议使用二分查找来确定可以推送的数量，但由于推送之间的等待时间可能很长，这可能会很困难。此外，许多仓库有一个非常大的第一次提交，或者在那之后的某些提交非常大。如果您知道这样的提交，请尝试单独推送它们。如果您的仓库足够小，最好只推送一个提交。否则，尝试推送20-30个提交，如果遇到问题，则减少数量。

2. 假设您只有一个分支master，请在同一位置创建一个新分支，例如master-temp。

3. 将master重置为要推送的第一组中的最后一个提交。例如：git reset --hard master-temp~100。

4. 推送该提交（git push）。

5. 在下一组的最后一个提交处进行--ff合并。（git merge --ff-only master-temp~90）

6. 重复步骤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 日志很干净，因为我花了很多时间学习如何编写出色的提交消息，并且我总是保持我的提交原子性。

别担心，完成后您仍将获得原始历史记录。

回到（更新后的）示例存储库：

* 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

（巨大的提交可以在任何地方，或者可能有多个。）

（总体思路是，您可以进行交互式变基（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足够聪明，可以重复使用您已经推送的项目，即使它们在不同的提交中。（请注意，分析对象步骤是最耗时的步骤。这是Git计算可以重复使用多少内容以及需要上传多少内容。）如果您想了解更多关于这是如何工作的，请查看Git内部文档中的Packfiles章节，也许在Git对象方面进行了解之后再查看。

我有提到过Git非常棒吗？

- Scott Weldon

Answer 5

“奇怪的是，原始URL没有“.git”在两台Linux机器和一个Windows桌面上成功了，但在第三台Linux机器上失败了。包含“.git”可以使其在所有机器上工作。”

“可能是Git版本太旧了。”

- 张永哲