解決 .git 目錄過(guò)大問(wèn)題

• 01、問(wèn)題描述
• 02、原因解釋
• 03、解決方法
• 04、總結(jié)教訓(xùn)

紙上得來(lái)終覺(jué)淺，絕知此事要躬行。

Git?是一個(gè)分布式版本控制軟件，最初由?林納斯·托瓦茲?創(chuàng)作，于?2005?年發(fā)布。最初目的是為更好地管理?Linux?內(nèi)核開(kāi)發(fā)。Git?在本地磁盤(pán)上就保存著所有有關(guān)當(dāng)前項(xiàng)目的歷史更新，處理速度快。Git?中的絕大多數(shù)操作都只需要訪問(wèn)本地文件和資源，不用實(shí)時(shí)聯(lián)網(wǎng)。

• Git LFS(Large File Storage?- ??件存儲(chǔ)）是可以把?樂(lè)、圖?、視頻等指定的任意?件存在?Git?倉(cāng)庫(kù)之外，?在?Git?倉(cāng)庫(kù)中??個(gè)占?空間?1KB?不到的?本指針來(lái)代替的??具。通過(guò)把??件存儲(chǔ)在?Git?倉(cāng)庫(kù)之外，可以減??Git?倉(cāng)庫(kù)本身的體積，使克隆?Git?倉(cāng)庫(kù)的速度加快，也使得?Git?不會(huì)因?yàn)閭}(cāng)庫(kù)中充滿??件?損失性能。
• 使??Git LFS，在默認(rèn)情況下，只有當(dāng)前簽出的?commit?下的?LFS?對(duì)象的當(dāng)前版本會(huì)被下載。此外，我們也可以做配置，只取由?Git LFS?管理的某些特定?件的實(shí)際內(nèi)容，?對(duì)于其他由?Git LFS?管理的?件則只保留?件指針，從?節(jié)省帶寬，加快克隆倉(cāng)庫(kù)的速度；也可以配置?次獲取??件的最近版本，從?能?便地檢查??件的近期變動(dòng)。

解決.git目錄過(guò)大問(wèn)題

01、問(wèn)題描述

發(fā)現(xiàn)問(wèn)題，然后判斷病因！

• 我們使用過(guò)?Git?的同學(xué)都知道，隨著代碼的更新迭代，倉(cāng)庫(kù)的體積越來(lái)越大。如果操作和使用都比較恰當(dāng)?shù)那闆r下，倉(cāng)庫(kù)體積不會(huì)突增的。但是如果使用不恰當(dāng)?shù)脑?，那就非常尷尬了，比如我們下面要說(shuō)的這種情況，.git?這個(gè)隱藏目錄特別大。
• 雖然?.git?這個(gè)隱藏目錄并不算在代碼體積之后，但是我們拉代碼的時(shí)候，是需要拉下來(lái)的，因?yàn)槔锩姘暗奶峤挥涗浀刃畔ⅰ＿@就會(huì)導(dǎo)致，原本平和的心情變得焦躁了，因?yàn)橄螺d速度變的很慢。

???du?-d?1?-h
680M????./.git
500K????./misc
?68K????./docker
...
1.1G????.

02、原因解釋

需要對(duì) Git 的工作原理要有一定的理解，才可以明白！

• 當(dāng)我們使用?git add?和?git commit?命令的過(guò)程中，Git?不知不覺(jué)就會(huì)幫我們創(chuàng)建出來(lái)了?blob?文件對(duì)象，然后更新?index?索引，再然后創(chuàng)建?tree?對(duì)象，最后創(chuàng)建出了?commit?對(duì)象。這些?commit?對(duì)象指向了頂層?tree?對(duì)象以及先前的?commit?對(duì)象。
• 而上述創(chuàng)建出來(lái)的對(duì)象，都以文件的方式保存在?.git/objects?目錄下。所以，當(dāng)我們?cè)谑褂玫倪^(guò)程中，提交了一個(gè)體積特別大的文件，就會(huì)被?Git?追蹤記錄在?.git/objects?文件夾下面。
• 此時(shí)，如果我們?cè)俅蝿h除這個(gè)體積特別大的文件，其實(shí)?Git?只會(huì)記錄了我們刪除的這個(gè)操作，但并不會(huì)把文件從?.git?文件夾下面真正的刪除，即?.git?文件夾完全不會(huì)變小。

03、解決方法

根本上的解決方式就是，及時(shí)使用?lfs?來(lái)追蹤記錄大文件！

• [方法一] 重建倉(cāng)庫(kù)

重建倉(cāng)庫(kù)的這種做法，算是一種比較一勞永逸且相對(duì)而言比較簡(jiǎn)單的方式。既然現(xiàn)在的倉(cāng)庫(kù)已經(jīng)讓我們無(wú)法忍受，與其這樣，還不是刪除重建來(lái)的爽快。但是，這種做法一般情況下，都是不可行，除非是自己的本地項(xiàng)目。

• [方法二] 刪除大文件

第二種做法就是，直接找到?.git?目錄下的大文件，將其刪除掉，之后推送到遠(yuǎn)程代碼庫(kù)里面。這樣做的前提是，刪除所有其他分支，保留?master?或者?main?分支。這里需要注意的是，操作有風(fēng)險(xiǎn)，后果請(qǐng)自負(fù)。

##?查找大文件
$?git?verify-pack?-v?.git/objects/pack/*.idx
12235d...dewaaaa34?tree???135?137?144088922
a453ab...34se212qz?blob???3695898?695871?144734158
......

##?篩除前五個(gè)且保留第一列
$?git?verify-pack?\
????-v?.git/objects/pack/*.idx?|?\
????sort?-k?3?-n?|?tail?-5?|?awk?'{print$1}'
12q626a...23a3
2z32ax1...azfd
......

##?查找出最大的5個(gè)文件和對(duì)應(yīng)Commit信息
$?git?rev-list?--objects?--all?|?\
????grep?"$(git?verify-pack?-v?.git/objects/pack/*.idx?|?\
????sort?-k?3?-n?|?tail?-5?|?awk?'{print$1}')"
91266a...sdfa3????data/xxx.pkl
232ax1...acafd????data/yyy.pkl
......

##?rev-list:????列出Git倉(cāng)庫(kù)中的所有提交記錄
##?--objects:???列出該提交涉及的所有文件ID
##?--all:???????所有分支的提交(位于/refs下的所有引用)
##?verify-pack:?顯示已打包的內(nèi)容(找大文件)

##?將其刪除掉
$?git?filter-branch?\
????--force?--prune-empty?--index-filter?\
????"git?rm?-rf?--cached?--ignore-unmatch?YOU-FILE-NAME"?\
????--tag-name-filter?cat?--?--all

##?filter-branch:??重寫(xiě)Git倉(cāng)庫(kù)中的提交
##?--index-filter:?指定后面命令進(jìn)行刪除
##?--all:??????????所有分支的提交(位于/refs下的所有引用)

##?強(qiáng)制推送
$?git?push?--force?--all

##?徹底清除
$?rm?-rf?.git/refs/original/
$?git?reflog?expire?--expire=now?--all
$?git?gc?--prune=now

• [方法三] 使用工具清理

幸好，Github?上面有一個(gè)叫做 git-filter-branch 的工具，就是幫助我們來(lái)清理大文件對(duì)象的，其使用?Scala?語(yǔ)言進(jìn)行編寫(xiě)的，且操作起來(lái)也十分方便。只需要簡(jiǎn)單幾步，就可以完成我們的需要。最新版需要確保本地的?java?為?Jdk8+。

##?下載封裝好的jar包
$?wget?https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar

##?克隆的時(shí)候需要--mirror參數(shù)
$?git?clone?--mirror?git://example.com/big-repo.git

##?運(yùn)行BFG來(lái)清理存儲(chǔ)庫(kù)
$?java?-jar?bfg.jar?--strip-blobs-bigger-than?100M?big-repo.git

##?去除臟數(shù)據(jù)
$?cd?big-repo.git
$?git?reflog?expire?--expire=now?--all
$?git?gc?--prune=now?--aggressive

##?推送上去
##?此推將更新遠(yuǎn)程服務(wù)器上的所有refs分支
$?git?push

##?刪除所有的名為'id_dsa'或'id_rsa'的文件
$?java?-jar?bfg.jar?--delete-files?id_{dsa,rsa}??my-repo.git

##?刪除所有大于50M的文件
$?java?-jar?bfg.jar?--strip-blobs-bigger-than?50M??my-repo.git

##?刪除文件夾下所有的文件
$?java?-jar?bfg.jar?--delete-folders?doc??my-repo.git

• [方法四] 使用 migrate 命令優(yōu)化 .git 目錄

遷移已有的?git?倉(cāng)庫(kù)，使??git lfs?來(lái)進(jìn)行管理。重寫(xiě)歷史后的提交需執(zhí)??git commit --force，請(qǐng)確認(rèn)在本地的操作合適?誤后再進(jìn)?提交。如有遷移??git lfs?前的倉(cāng)庫(kù)有多份拷?，其他拷?可能需要執(zhí)??git reset --hard origin/master?來(lái)重置其本地的分?，注意執(zhí)??git reset --hard?命令將會(huì)丟失本地的改動(dòng)。

##?重寫(xiě)master分?
##?將歷史提交(指的是.git目錄)中的*.zip都?lfs進(jìn)?管理
$?git?lfs?migrate?import?--include-ref=master?--include="*.zip"

##?重寫(xiě)所有分?及標(biāo)簽
##?將歷史提交(指的是.git目錄)中的*.rar,*.zip都?lfs進(jìn)?管理
$?git?lfs?migrate?import?--everything?--include="*.rar,*.zip"

##?切換后需要把切換之后的本地分支提交到遠(yuǎn)程倉(cāng)庫(kù)了，需要手動(dòng)push更新遠(yuǎn)程倉(cāng)庫(kù)中的各個(gè)分支
$?git?lfs?push?--force

##?切換成功后，GIT倉(cāng)庫(kù)的大小可能并沒(méi)有變化
##?主要原因可能是之前的提交還在，因此需要做一些清理工作
##?如果不是歷史記錄非常重要的倉(cāng)庫(kù)，建議不要像上述這么做，而是重新建立一個(gè)新的倉(cāng)庫(kù)
$?git?reflog?expire?--expire-unreachable=now?--all
$?git?gc?--prune=now

04、總結(jié)教訓(xùn)

勤于思考，必中頭榜！

比較好的避免上述問(wèn)題的出現(xiàn)，就是及時(shí)使用?lfs?來(lái)追蹤、記錄和管理大文件。這樣大文件既不會(huì)污染我們的?.git?目錄，也可以讓我們更方便的使用。

##?1.開(kāi)啟lfs功能
$?git?lfs?install

##?2.追蹤所有后綴名為“.psd”的文件
$?git?lfs?track?"*.iso"

##?3.追蹤單個(gè)文件
git?lfs?track?"logo.png"

##?4.提交存儲(chǔ)信息文件
$?git?add?.gitattributes

##?5.提交并推送到GitHub倉(cāng)庫(kù)
$?git?add?.
$?git?commit?-m?"Add?some?files"
$?git?push?origin?master

同時(shí)，還有一個(gè)方法，就是靈活使用?.gitignore?文件，及時(shí)排除我們倉(cāng)庫(kù)不需要的特殊目錄或者文件，從而不會(huì)讓不應(yīng)該存在的文件，出現(xiàn)在我們的代碼倉(cāng)庫(kù)里面。

.DS_Store
node_modules
/dist

*.zip
*.tar.gz