很久沒有寫博客了，最近遇到了一個(gè)git問題，比較典型，記錄下來與大家分享。
我們使用git版本控制的時(shí)候享受了很多便利，不管是代碼合并，分支提供給我們的并發(fā),但我們也往往忽略了每次提交之后在我們本地項(xiàng)目根目錄下.git文件夾里面的存儲(chǔ)變化。我遇到的git“臃腫”問題就是因?yàn)樵谔峤坏臅r(shí)候把較大文本加入版本控制，在其他人拉取更新反推遠(yuǎn)程分支的時(shí)候，每一次都會(huì)加劇.git下面的objects的文件夾大小，最終的結(jié)果就是再也無法順利從遠(yuǎn)程pull，也無法順利clone該項(xiàng)目。
關(guān)于.git的產(chǎn)生和相關(guān)文件，可見此文的詳細(xì)講解：http://www.jianshu.com/p/fa31ef8814d2 。
簡單的說，每一次提交修改的改變都會(huì)以文件的形式存儲(chǔ)在本地項(xiàng)目根目錄下的.git中，會(huì)在.git/objects下面形成一個(gè)Blob（一段二進(jìn)制數(shù)據(jù)）文件記錄。這意味著，即使你只改動(dòng)了某個(gè)文件的一行內(nèi)容，Git 也會(huì)生成一個(gè)全新的對象來存儲(chǔ)新的文件內(nèi)容。所以git倉庫隨著時(shí)間變化會(huì)自增長，我們往往忽視了這種潛在的危險(xiǎn)。
下面來就我遇到的問題來思考解決方案，其實(shí)由于.git過大，我們可以從兩種方向去思考，第一種治標(biāo)不治本的方法：壓縮git倉庫。第二種刪除git提交記錄中大文件，在gc壓縮。第一種方法是比較直接快捷的，可以使用命令：git gc --prune=now。 當(dāng)你再次du -hs的時(shí)候會(huì)發(fā)現(xiàn)倉庫大小有一定的變小。其實(shí)git自身在可承受范圍內(nèi)會(huì)自動(dòng)用gc幫你壓縮打包，所以除非真的遇到pull,push都困難的時(shí)候，可以不用手動(dòng)執(zhí)行。這個(gè)方法明顯的缺點(diǎn)在于壓縮的效果有限，且大文件還一直在之后的每次提交中，為以后埋下隱患。
本人更推薦第二種方法，大文件對象再刪除。
先查找大文件，命令如下：
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')"
