我们使用git版本控制的时候享受了很多便利，不管是代码合并，分支提供给我们的并发,但我们也往往忽略了每次提交之后在我们本地项目根目录 下.git文件夹里面的存储变化。我遇到的git“臃肿”问题就是因为在提交的时候把较大文本加入版本控制，在其他人拉取更新反推远程分支的时候，每一次 都会加剧.git下面的objects的文件夹大小，最终的结果就是再也无法顺利从远程pull，也无法顺利clone该项目。
关于.git的产生和相关文件，可见此文的详细讲解：http://www.jianshu.com/p/fa31ef8814d2 。
简单的说，每一次提交修改的改变都会以文件的形式存储在本地项目根目录下的.git中，会在.git/objects下面形成一个 Blob（一段二进制数据）文件记录。这意味着，即使你只改动了某个文件的一行内容，Git 也会生成一个全新的对象来存储新的文件内容。所以git仓库随着时间变化会自增长，我们往往忽视了这种潜在的危险。
下面来就我遇到的问题来思考解 决方案，其实由于.git过大，我们可以从两种方向去思考，第一种治标不治本的方法：压缩git仓库。第二种删除git提交记录中大文件，在gc压缩。第 一种方法是比较直接快捷的，可以使用命令：git gc –prune=now。 当你再次du -hs的时候会发现仓库大小有一定的变小。其实git自身在可承受范围内会自动用gc帮你压缩打包，所以除非真的遇到pull,push都困难的时候，可 以不用手动执行。这个方法明显的缺点在于压缩的效果有限，且大文件还一直在之后的每次提交中，为以后埋下隐患。
本人更推荐第二种方法，大文件对象再删除。
先查找大文件，命令如下：
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')"
例如删除nspatientList1.txt文件：
git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch bin/nspatientList1.txt' --prune-empty --tag-name-filter cat -- --s
删除之后会有大量输出，显示已经从各自历史log中剔除掉关于这个大文件的信息，之后可以使用gc命令再次压缩:
git gc --prune=now
然后再进行提交即可。
你再次使用du相关命令检测文件夹大小会惊奇地发现大幅度缩小。
当然也有人会说，这是你不断地粗鲁地merge造成的结果，所以也可以去使用rebase命令来衍合你的分支代码，让整个历史log变成干净清晰的一条直线。
关于rebase的使用可以参考官方文档，一旦你接受了这种方式，你的git log会变得更美观，也更符合人性。
你的反应是：