git push到遠(yuǎn)程服務(wù)器出現(xiàn)RPC failed問題怎么解決

本篇內(nèi)容主要講解“git push到遠(yuǎn)程服務(wù)器出現(xiàn)RPC failed問題怎么解決”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“git push到遠(yuǎn)程服務(wù)器出現(xiàn)RPC failed問題怎么解決”吧!

git提交報錯

error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413fatal: the remote end hung up unexpectedlyfatal: the remote end hung up unexpectedlyEverything up-to-date

解決方案

方案一：修改本地git postbuffer大小

git config --global http.postbuffer 524288000

方案二：修改項(xiàng)目.git/config文件，增加如下內(nèi)容

[http]      postBuffer = 524288000

方案三：用管理賬號在gitlab中的Account and limit加大Maximum attachment size (MB)和Maximum push size (MB)

問題復(fù)盤

1、先看git push拋出來的問題

error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413

對我們有效的信息，預(yù)計(jì)就是413這個狀態(tài)碼，我們可以先從這個狀態(tài)碼入手

這個狀態(tài)碼的含義是

413 Request Entity Too Large
服務(wù)器拒絕解決當(dāng)前請求，由于該請求提交的實(shí)體數(shù)據(jù)大小超過了服務(wù)器愿意或者者能夠解決的范圍。此種情況下，服務(wù)器可以關(guān)閉連接以免用戶端繼續(xù)發(fā)送此請求。

由狀態(tài)碼的含義，我們可以得出上傳的代碼可能過大。于是我讓小伙伴看下，他上傳的代碼量有多少，好家伙，一共有4,50M的大小

2、處理方案

方案一：代碼進(jìn)行分批上傳，不要一次性上傳

小伙伴按這個方案果然處理了問題，但是他說這樣好麻煩，總不能以后每次都要分批上傳，這樣提交代碼的效率很低

方案二：增大http方式上傳的大小

這個方案就是最開始的設(shè)置postbuffer，但問題就是不論用。后面就懷疑說是不是由于配置域名的起因，于是我就采用內(nèi)網(wǎng)ip的方式直接去push代碼，結(jié)果竟然可以了。

接著去ping下gitlab的域名，發(fā)現(xiàn)那個ip不是gitlab的內(nèi)網(wǎng)ip，當(dāng)然ping出來的也可能是外網(wǎng)ip，于是我就把ping出來的ip通過百度一下，顯示該ip是本地局域網(wǎng)。

而后很自然的想到項(xiàng)目的gitlab是不是配置了代理商，接著就去問搭這個gitlab的前同事。果然他之前搭建這套gitlab采用nginx做了代理商，于是衍生出了第三種方案

方案三：修改nginx配置

在http的server節(jié)點(diǎn)中增加client_max_body_size，形如下

http: {    server: {        client_max_body_size: 200m;    }}

方案四：用ssh提交代碼

到此，相信大家對“git push到遠(yuǎn)程服務(wù)器出現(xiàn)RPC failed問題怎么解決”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！