git惨案—提交文件过大导致RPC failed，413 Req

本文首发于公众号“AntDream”，欢迎微信搜索“AntDream”或扫描文章底部二维码关注，和我一起每天进步一点点

今天git push的时候碰到个奇怪的问题，push的进度卡在25%，最后提交失败，报上述图片中的错误。看提交的过程日志发现竟然有1个多G的内容要提交！而正常的情况下一般几秒钟就OK了，而且我也没有改动几个文件呀？！

上图是正常的情况，可以看到实际上只有几KB，嗖的一下就好了

问题解决过程

上网找来找去，发现推送文件过大，提交失败，是因为采用Http推送，服务器的nginx会有最大文件的限制。网上一般是2种解决方法：

方法一：切换成ssh提交

• 首先用git remote -v命令查看远程的仓库地址是否是http开头的
• 如果是，那就切换为ssh开头的链接，命令为：git remote set-url origin ssh链接

而实际上，第一种方法我试了，切换为ssh提交以后还是很慢，我懒得等，就想别的方法了。

个人认为，对于我的情况，以上2种都是治标不治本。问题的关键在于为什么我有这么大的文件需要提交？！

最后通过一个个查找最近的commit，发现之前的一个commit中有一个之前没见过的文件java_pid52529.hprof

而这个文件有1.5G！所以这才是罪魁祸首！

解决步骤：

1. 首先就是回滚到有问题的那次提交，注意这里的回滚当然不能丢掉我们已经改动过的代码

   //用下面的命令可以回滚commit和add命令
   git reset --mixed HEAD^
   

   上面的命令会回滚最近的一次commit和add操作，但是改动的代码仍然再，相当于是要重新提交。如果出问题的是之前的某次commit，那就多执行几次上面的命令。

2. 回滚到有问题的那次commit之后，删除掉有问题的文件，然后重新提交

   //删除文件
   rm java_pid52529.hprof
   //然后重新提交
   git add .
   git commit -m "重新提交"
   

通过以上就能根本上解决问题了。

总结

一般情况下，我们提交git是不会碰到这个问题，特别是之前是正常的，突然之间提交文件变成几百兆，可以看看是不是提交了不该提交的文件。

java_pid52529.hprof 这个文件看这个后缀hprof，应该是内存快照，我们在分析是否有内存泄漏时一般都会用IDE工具截取一段APP的内存记录，生成这个hprof文件，然后进行分析。

                       欢迎关注我的微信公众号，和我一起每天进步一点点！