很久沒有寫博客了，最近遇到了一個git問題，比較典型，記錄下來與大家分享。
我們使用git版本控制的時候享受了很多便利，不管是代碼合并，分支提供給我們的并發(fā),但我們也往往忽略了每次提交之后在我們本地項目根目錄下.git文件夾里面的存儲變化。我遇到的git“臃腫”問題就是因為在提交的時候把較大文本加入版本控制，在其他人拉取更新反推遠(yuǎn)程分支的時候，每一次都會加劇.git下面的objects的文件夾大小，最終的結(jié)果就是再也無法順利從遠(yuǎn)程pull，也無法順利clone該項目。
關(guān)于.git的產(chǎn)生和相關(guān)文件，可見此文的詳細(xì)講解：http://www.jianshu.com/p/fa31ef8814d2 。
簡單的說，每一次提交修改的改變都會以文件的形式存儲在本地項目根目錄下的.git中，會在.git/objects下面形成一個Blob（一段二進(jìn)制數(shù)據(jù)）文件記錄。這意味著，即使你只改動了某個文件的一行內(nèi)容，Git 也會生成一個全新的對象來存儲新的文件內(nèi)容。所以git倉庫隨著時間變化會自增長，我們往往忽視了這種潛在的危險。
下面來就我遇到的問題來思考解決方案，其實由于.git過大，我們可以從兩種方向去思考，第一種治標(biāo)不治本的方法：壓縮git倉庫。第二種刪除git提交記錄中大文件，在gc壓縮。第一種方法是比較直接快捷的，可以使用命令：git gc --prune=now。 當(dāng)你再次du -hs的時候會發(fā)現(xiàn)倉庫大小有一定的變小。其實git自身在可承受范圍內(nèi)會自動用gc幫你壓縮打包，所以除非真的遇到pull,push都困難的時候，可以不用手動執(zhí)行。這個方法明顯的缺點在于壓縮的效果有限，且大文件還一直在之后的每次提交中，為以后埋下隱患。
本人更推薦第二種方法，大文件對象再刪除。
先查找大文件，命令如下：
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')"
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學(xué)習(xí)是年輕人改變自己的最好方式