蓝字

最近小组成员跟我说，他git提交不了代码。我问了下原因，他说他代码一提交就会报

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

然后他跟我说他百度几种方法，都不管用。下文列下他百度出来的方案

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

git config --global http.postbuffer 524288000

方案二：修改项目.git/config文件，添加如下内容

[http] 
    postBuffer = 524288000

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

可以参考该链接

https://blog.csdn.net/techfield/article/details/70198077

因为小伙伴不是管理员，后面我尝试了该方案，不管用

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

对我们有效的信息，估计就是413这个状态码，我们可以先从这个状态码入手。这个状态码的含义是

413 Request Entity Too Large

服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。

注： 查看http状态码信息，可以通过https://www.php.cn/web/web-http.html进行查阅

由状态码的含义，我们可以得出上传的代码可能过大。于是我让小伙伴看下，他上传的代码量有多少，好家伙，一共有4,50M的大小

方案一：代码进行分批上传，不要一次性上传

小伙伴按这个方案果然解决了问题，但是他说这样好麻烦，总不能以后每次都要分批上传，这样提交代码的效率很低

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

这个方案就是最开始的设置postbuffer，但问题就是不管用。后面就怀疑说是不是因为配置域名的原因，于是我就采用内网ip的方式直接去push代码，结果竟然可以了。

接着去ping下gitlab的域名，发现那个ip不是gitlab的内网ip，当然ping出来的也可能是外网ip，于是我就把ping出来的ip通过百度一下，显示该ip是本地局域网。

然后很自然的想到项目的gitlab是不是配置了代理，接着就去问搭这个gitlab的前同事。果然他之前搭建这套gitlab采用nginx做了代理，于是衍生出了第三种方案

方案三：修改nginx配置

在http的server节点中添加client_max_body_size，形如下

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

配置ssh，可以参考如下链接https://blog.csdn.net/qq_42832446/article/details/105533733