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

Git error: RPC failed; result=22, HTTP code = 404

提问by guinzu

I'm using SourceTree on OSX and using Git to push to Visual Studio Online. I get the following error:

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

POST git-receive-pack (490857233 bytes)
error: RPC failed; result=22, HTTP code = 404
fatal: The remote end hung up unexpectedly
Everything up-to-date
Completed with errors, see above

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

I have already tried the following:

我已经尝试了以下方法：

git config --global http.postBuffer 524288000

回答by user2711915

I just ran into a very similar error (for which this answer is the top google result) - the solution was in a comment by @Liviu Chircu

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

The solution was to put the .giton the end of the url

解决方案是将 放在.giturl 的末尾

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

However:

然而：

git clone http://myURL/projectname.git

succeeded.

成功了。

The strange thing is that the original URL without .gitsucceeded on two linux machines and a windows desktop, but failed on a third linux machine. Including .gitmakes it work on all machines.

奇怪的是，原来的 URL 没有.git在两台 linux 机器和 Windows 桌面上成功，但在第三台 linux 机器上失败。包括.git使它在所有机器上都能工作。

回答by Oxymoron

Your repository may be to big, Try to upload in chunks, like using GIT to revert back halfway in the history or so in a new branch, push that, then push the latest commits.

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

Probably a better workaround, but this is what I was able to do to quickly solve my issue

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

I was able to push 108.61 MiB, but not 144.64 MiB

我能够推送 108.61 MiB，但不能推送 144.64 MiB

Hope this helps.

希望这可以帮助。

回答by Scott Weldon

June 2016 Update:According to this page:

2016 年 6 月更新：根据此页面：

SSH authentication to Team Services Git repos is currently in private preview

Team Services Git 存储库的 SSH 身份验证目前处于私有预览阶段

I recommend that you switch to SSH authentication if you are able to, because this should avoid this issue altogether. (Note that you are able to use HTTPS and SSH in tandem, even on the same machine.)

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

If this hasn't been enabled for you yet, or you are otherwise unable to switch to SSH, keep reading.

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

---

---

Original Post:

原帖：

As @Oxymoron mentioned, the problem is that your repository is too big, or more specifically, you are trying to push too much at once.

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

What? That doesn't make sense! That's not what the HTTP 404code is for!

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

It doesn't make sense to me either. *glares in Microsoft's general direction*

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

You probably already ran into this and got an error like this:

你可能已经遇到了这个问题，并得到了这样的错误：

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

And that is likely what led you to do the git configcommand that you mentioned.

这可能是导致您执行git config您提到的命令的原因。

Now for the purpose of my posting a separate answer: I'd like to expand on how you can fix this. You will still try to push a smaller set of commits at a time, but this is not always as easy as it sounds. Here is the process:

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

1. Determine how many commits to push at a time. I would normally recommend a binary search to determine how much you can push, but this can be difficult because of the wait time in between pushes. Also, many repos have a very large first commit, or certain commits after that are very large. If you know of such commits, try to push those by themselves. If your repo is small enough, it might be easiest to just push one commit at a time. Otherwise, try to push 20-30 commits, decreasing the number if you run into issues.

2. Assuming you have one branch, master, create a new branch at the same place, e.g. master-temp.

3. Reset masterto the last commit in the first group that you want to push. E.g. git reset --hard master-temp~100.

4. Push that commit (git push).

5. Do a --ffmerge at the last commit of the next group. (git merge --ff-only master-temp~90)

6. Repeat steps 4 and 5 until all commits are pushed.

1. 确定一次推送多少次提交。我通常会推荐一个二分搜索来确定你可以推送多少，但这可能很困难，因为推送之间的等待时间。此外，许多存储库的第一次提交非常大，或者之后的某些提交非常大。如果您知道此类提交，请尝试自行推动这些提交。如果你的 repo 足够小，一次只推送一个提交可能是最简单的。否则，尝试推送 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 步，直到推送所有提交。

As an example, consider this repo:

例如，考虑这个 repo：

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

This is what you will do, assuming that you want to push one commit at a time:

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

$ 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

Ideally, that works fine, and you're done. But what happens if a given commit can't be pushed, even if that is the only commit you are pushing? First, try pushing once or twice more; there seems to be some inconsistency in how much it takes to fail the push.

理想情况下，这工作正常，您就完成了。但是，如果给定的提交无法推送，即使这是您推送的唯一提交，会发生什么？首先，尝试再推一两次；推动失败所需的时间似乎有些不一致。

If it still won't push, then it's time to rewrite history.

如果它仍然不会推送，那么是时候重写历史了。

But I don't want to rewrite my history! My Git log is nice and clean, because I spent lots of time learning how to write great commit messages, and I always keep my commits atomic.

但我不想改写我的历史！我的 Git 日志很好而且很干净，因为我花了很多时间学习如何编写出色的提交消息，而且我始终保持提交原子性。

Don't worry, you'll still get your original history when you're done.

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

Back to the (updated) example 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

(The massive commit can be anywhere, or there can be more than one.)

（大规模提交可以在任何地方，也可以不止一个。）

The general idea is, you do a interactive rebase (git rebase -i) to split the massive commit into a few smaller ones.

总体思路是，您执行交互式 rebase ( git rebase -i)将大量提交拆分为几个较小的提交。

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

Note: The --rootis only needed if you need to split the very first commit. Otherwise do e.g. git rebase -i bbbbbbb.

注意：--root仅当您需要拆分第一个提交时才需要。否则做例如git rebase -i bbbbbbb。

Change the commit that you want to split from pickto edit.

将要拆分的提交更改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

Now this is where the magitmagic happens:

现在这是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'

The last command will succeed, because Git is smart enough to reuse the items you have already pushed, even if they are in a different commit. (Notice that the Analyzing objectsstep is the one that takes the longest. This is Git calculating how much it can reuse, and how much it needs to upload.) If you are interested in learning more about how this works, check out the Packfiles section of the Git Internals docs, perhaps after brushing up on Git Objects.

最后一个命令会成功，因为 Git 足够聪明，可以重用您已经推送的项目，即使它们在不同的 commit 中。（请注意，这Analyzing objects一步是耗时最长的一步。这是 Git 计算可以重用多少以及需要上传多少。）如果您有兴趣了解有关其工作原理的更多信息，请查看Packfiles 部分Git Internals 文档，可能是在复习了Git Objects 之后。

Have I mentioned that Git is awesome?

我有没有提到 Git 很棒？