一直有對二進(jìn)制文檔版本控制的需求畔况，比如一些修圖的文檔，圖片庫什么的慧库。之前不懂跷跪，一直在用原生git進(jìn)行控制，結(jié)果原本的2G文件夾齐板，很快變成了4G+吵瞻。
然后參考了git文檔發(fā)現(xiàn)，官方是不推薦git進(jìn)行二進(jìn)制文檔控制的甘磨。
然后順著思路找橡羞，發(fā)現(xiàn)二進(jìn)制版本控制是有的，而且是git系統(tǒng)能提供的：Git LFS济舆。
Git LFS需要單獨(dú)下載卿泽，看似是獨(dú)立于git的另一個程序，但其實(shí)只是相當(dāng)于一個git插件的存在滋觉。
主要好處有：
- 邏輯變了签夭，運(yùn)行速度就加快了。
問題：
- 使用了Git LFS后椎侠，只不過體積增大問題還是沒解決第租。2G的圖片倉庫還是會翻倍變成5G+，多出來的全都在
.git/lfs/objects文件夾中（以前是存在.git/objects中）我纪。
參考Github官方：Git Large File Storage
安裝和初始配置
# Mac
$ brew install git-lfs
初始配置（只需要在第一次安裝時配置一次）：
$ git lfs install
生成和配置本地項(xiàng)目
到這里慎宾，就要進(jìn)入lfs領(lǐng)域了。需要說明的是浅悉，
其實(shí)絕大多數(shù)時間里趟据，你都還是在使用原生的git命令。
我在一開始用時仇冯，腦袋非持蓿混亂：到底怎么看待git lfs？另一套程序苛坚？還是git的一個指令比被？
其實(shí)都不是，如果非要說的話泼舱，把它看出git的一個extension插件，看成一個Filter過濾器更為方便娇昙。
現(xiàn)在來說一個典型的Git LFS Workflow流程：
- 打開一個本地文件夾
-
git init初始化為git倉庫 -
git lfs track指定監(jiān)控的LFS大文件類型 -
git add . && git commit正常添加尺迂、提交倉庫變化 -
git lfs push通過lfs優(yōu)化推送到遠(yuǎn)程 - 修改一些文件
-
git add . & git commit -m "update"正常git流程 - 修改一些文件
-
git add . & git commit -m "update"正常git流程 - 修改一些文件
-
git add . & git commit -m "update"正常git流程 -
git lfs pull通過lfs優(yōu)化更新本地倉庫 git lfs push
實(shí)際上噪裕，Git LFS在這里的作用是一個Filter，把大文件過濾出來膳音，不對它使用文本的處理方式增大體積召衔，而采用另一套方案處理祭陷。
所以你只要一開始建立好filter，后面就不用再管了兵志。
# 指定監(jiān)視的文件類型
$ git lfs track "*.jpg"
$ git lfs track "*.png"
$ git lfs track "*.jpeg"
連接遠(yuǎn)程倉庫
使用的Gitlab來做LFS倉庫時，第一次push會出現(xiàn)以下消息：
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs.https://gitlab.com/jason/test.git/info/lfs.locksverify true
然后照著它的提示想罕，輸入命令后再push，就沒有問題了弧呐。
常用的Git LFS遠(yuǎn)程連接有幾項(xiàng)常用方法：
$ git lfs clone <URL>
$ git lfs pull
$ git lfs push
# 斷點(diǎn)續(xù)傳（GB級別的倉庫常用）
$ git lfs fetch
這幾項(xiàng)至關(guān)重要嵌纲，如果沒有加lfs三個字的話俘枫，效率真的極低逮走。
lfs的遠(yuǎn)程邏輯完全不同：
比如下載文件的話，不像git原生一個一個下載师溅，lfs是先把所有文件夾茅信、文件名都創(chuàng)建好墓臭，然后再把真實(shí)所需的文件下載下來。
注意事項(xiàng)
一定要git lfs clone, git lfs push和 git lfs pull
如果不是使用git lsf指令clone窿锉、push酌摇、pull的話，git就會按照正常的步驟把所有文件和所有版本全部下載下來嗡载，對二進(jìn)制文檔來說效率極低窑多。
所以注意這里一定要指定lfs!
