先說結(jié)論，git使用了Delta增量壓縮算法，git-lfs實(shí)測沒有進(jìn)行任何壓縮，這個(gè)結(jié)論讓我很震驚。

測試過程如下：

測試git倉庫自身的壓縮

準(zhǔn)備一個(gè)包含許多雜項(xiàng)文件的文件夾，大概幾百M(fèi)，要保證有一個(gè)txt文本文件，做修改用，我們就叫這個(gè)文件夾為[數(shù)據(jù)包]。

將[數(shù)據(jù)包]壓縮為TestFile.zip，我這里壓縮結(jié)果大小為115M，然后放進(jìn)本地倉庫里。

步驟1、將TestFile.zip進(jìn)行add、commit然后push到遠(yuǎn)程倉庫：

步驟2、對(duì)[數(shù)據(jù)包]中的一個(gè)txt文件稍做修改，依舊是壓縮為TestFile.zip，然后替換掉本地git倉庫的同名文件，從而模擬修改，再次執(zhí)行步驟1。

將步驟1、2這一過程循環(huán)執(zhí)行3遍，這樣的話，就意味著有三個(gè)115M大小的文件被push到遠(yuǎn)程倉庫中，我們來驗(yàn)證一下遠(yuǎn)程中央倉庫大?。?/p>

如上所示，遠(yuǎn)程倉庫的大小確實(shí)是3*115=345M，也就是說，無論你連續(xù)幾次提交之間的差異有多小，在提交并推送時(shí)，遠(yuǎn)程倉庫并不會(huì)[立即]進(jìn)行Delta壓縮。

我們?cè)倏匆幌略蹅兊谋镜貍}庫大小：

本地倉庫顯示459M，實(shí)際也是合理的，因?yàn)楸镜貍}庫是[工作空間]+[倉庫]：

好了，下面就是見證git的壓縮技術(shù)的時(shí)候了，我們先在遠(yuǎn)程中央倉庫執(zhí)行壓縮命令git gc：

壓縮完之后，我們?cè)倏匆幌逻h(yuǎn)程倉庫的空間大小：

遠(yuǎn)程倉庫的空間變成了115M，和只傳了一個(gè)TestFile.zip占用的空間一樣，但確實(shí)是包含了三次commit的全部歷史版本數(shù)據(jù)，對(duì)每次的TestFile.zip文件的修改都能追溯。這說明了如果直接用git管理大文件，在歷次對(duì)大文件的修改不大的前提下，git的Delta壓縮會(huì)極大的節(jié)約空間，因?yàn)橹槐Ａ魵v次文件修改之間的區(qū)別。

我們?cè)賹?duì)本地倉庫進(jìn)行下git gc看看：

結(jié)果和遠(yuǎn)程倉庫一樣，除了工作空間不受影響以外，倉庫空間被極大的壓縮，但同樣在小體積的同時(shí)保留了所有對(duì)于TestFile.zip文件的歷次修改。

好了，以上就是git自身對(duì)于倉庫文件的壓縮，下面，咱們?cè)倏磄it-lfs，我原本以為git-lfs作為專為管理大文件而生的git擴(kuò)展，自然有對(duì)空間管理這方面的牛b之處，沒想到一番測試下來大跌眼鏡。

首先分別給遠(yuǎn)程中央倉庫與本地倉庫進(jìn)行l(wèi)fs的初始化：

命令：git lfs install

遠(yuǎn)程中央倉庫：

本地倉庫：

然后再從本地倉庫執(zhí)行以下命令git lfs track "*.mp4"，讓git-lfs負(fù)責(zé)管理.mp4格式的文件：

接下來將上面命令所生成的git-lfs配置文件.gitattributes推送到遠(yuǎn)程倉庫：

上面都妥當(dāng)之后，就該咱們的老朋友TestFile.zip登場了，他將繼續(xù)作為測試git-lfs大文件夾存儲(chǔ)壓縮方面的關(guān)鍵人。

TestFile.zip：唉？不對(duì)啊，你上面不是配置了只讓git-lfs管理mp4文件嗎？怎么還是我？

作者：你改下后綴名不就是個(gè)mp4了嘛！

TestFile.mp4：哦~，也是哦，真有你的……

好了，那就把[數(shù)據(jù)包]中的txt文件內(nèi)容稍作修改，依舊壓縮為TestFile.zip，然后改后綴名為TestFile.mp4，復(fù)制到本地倉庫中：

步驟1、將TestFile.mp4進(jìn)行add、commit然后push到遠(yuǎn)程倉庫：

步驟2、對(duì)[數(shù)據(jù)包]中的一個(gè)txt文件稍做修改，依舊是壓縮為TestFile.zip，然后依舊是改后綴名為TestFile.mp4，然后替換掉本地git倉庫的同名文件，從而模擬修改，再次執(zhí)行步驟1。

?將步驟1、2這一過程循環(huán)執(zhí)行3遍，這樣的話，就意味著有三個(gè)115M大小的文件被push到遠(yuǎn)程倉庫中，我們來驗(yàn)證一下遠(yuǎn)程中央倉庫大小：

?

我們發(fā)現(xiàn)遠(yuǎn)程倉庫的大小還是115m，那是因?yàn)檫h(yuǎn)程倉庫上的git倉庫與存儲(chǔ)大文件的lfs倉庫路徑是不同的，在部署gitea托管平臺(tái)的時(shí)候會(huì)設(shè)置lfs的路徑，所以我們到lfs路徑下去看看：

然后我們看一下本地倉庫，之前的三個(gè)TestFile.zip文件還是存放在objects文件夾下，還是占用114m，而lfs管理的mp4文件是存放到了新增加的lfs文件夾下了，三個(gè)mp4文件，3*115=345m：

好了，我們現(xiàn)在照貓畫虎，依舊是分別在遠(yuǎn)程倉庫與本地倉庫執(zhí)行g(shù)it gc命令進(jìn)行倉庫壓縮，看看會(huì)發(fā)生什么：

遠(yuǎn)程倉庫：

本地倉庫：

同樣是沒有任何變化：

不是，合著你git lfs是一點(diǎn)壓縮也不干?。磕呐氯齻€(gè)文件就只有一個(gè)字節(jié)的區(qū)別，你也是存三份？

git lfs：是啊，那我不就省下了壓縮與解壓縮的時(shí)間，不就更快了嘛！

我：我特么……

結(jié)論

就跟上面的實(shí)驗(yàn)一樣，如果你的大文件會(huì)經(jīng)常性的修改，你還是別用git lfs了，哪怕你一次只做一個(gè)字節(jié)的修改，git lfs也會(huì)完整的給你存一份，壓縮空間？只存增量？不存在的。你要是經(jīng)常改動(dòng)某些大文件，git lfs倉庫所在的服務(wù)器容量分分鐘給你擠爆了。當(dāng)然，你要說你服務(wù)器容量管夠，當(dāng)我沒說。

那么哪些文件適合放進(jìn)git lfs，我覺得要同時(shí)滿足這兩點(diǎn)：

1、很大

2、永遠(yuǎn)不會(huì)修改

如果不能同時(shí)滿足這兩點(diǎn)，勸你還是老老實(shí)實(shí)用git吧，或者用svn。

另外可能有些對(duì)git lfs有所了解的朋友會(huì)說：唉，不對(duì)啊，我記得git lfs有一個(gè)命令[git lfs prune]可以壓縮空間啊。

那我只能遺憾的告訴你，這條語句不會(huì)對(duì)遠(yuǎn)程中央倉庫產(chǎn)生半點(diǎn)影響，它只是暫時(shí)的將你本地用不到的lfs緩存文件給刪除掉，中央服務(wù)器中依然是存儲(chǔ)著過去的commit對(duì)于lfs緩存文件歷史版本的引用。也就是說你本地刪除掉的東西，隨時(shí)都能從中央倉庫down回來。

再次追加

我這兩天又在外網(wǎng)上查閱了不少關(guān)于git-lfs的相關(guān)資料，最后得出結(jié)論：

不要用git-lfs

不要用git-lfs

不要用git-lfs

實(shí)際上git-lfs的唯一好處就是可以讓使用人員在clone倉庫時(shí)不用下載所有文件，僅此而已，但隨著這兩年git的更新，也可以實(shí)現(xiàn)clone時(shí)不下載所有內(nèi)容了，所以git-lfs的唯一優(yōu)勢也基本沒有了。

在stack上上有關(guān)于這點(diǎn)的詳細(xì)討論，有興趣的可以去看看：

git lfs - How does git LFS track and store binary data more efficiently than git? - Stack Overflow

?git lfs - Do I need Git LFS for local repos? - Stack Overflow文章來源地址http://www.zghlxwxcb.cn/news/detail-799415.html

到了這里，關(guān)于關(guān)于git與git-lfs對(duì)文件壓縮存儲(chǔ)方面的研究的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！