GIT LFS如何对追踪的文件进行版本控制

既然GIT LFS能达到这种精简代码的效果，那GIT LFS到底是如何做的呢？

事实上，GIT LFS数据存储于GIT中普通文件类似,只是LFS文件被存储在.git下面的lfs文件夹下,而普通文件则被存储在.git下的objects文件夹下,在存储原理上是一致的，LFS特别不一样同时也是它精髓之处就在于: 它在本地仓库中并不保留所有的文件版本，而是仅根据需要提供检出版本中必需的文件，最终只会得到你真正想要的文件 - 而不是一些你可能永远都不需要冗余数据。

 

我们不妨以一个demo来验证下这个结论是否成立，在本地建立一个工程，用3个大小不一命名一样的.a静态库来模拟该文本的3个版本，这里把它们统一名称test.a文件,三个大小分别为: 版本1(5.2M), 版本2(1.8M), 版本3(555kb),一个一个提交上传到远端,这样test.a就被迭代了3个版本,

我们重新新建一个文件夹，终端下进入该文件目录下，先执行git lfs install初始化下lfs，接下来准备克隆仓库，我们知道，对于有LFS管理的仓库，在克隆时可以通过配置不下载任何LFS管理的文件，这样我们就可以快速克隆仓库本身，即执行GIT_LFS_SKIP_SMUDEGE=1  git clone xxx即可。这里分两种情况来克隆。

 

 

1. 允许下载LFS文件。

在终端输入：git clone git@code.paic.com.cn:haoshifu/test_gitlfs.git,将仓库克隆到本地,打开文件夹查看下test.a的大小

test.a文件大小为555kb，克隆的是版本3的内容, 在终端下查看提交历史:

我们切换到第二版本,在终端执行git reset –hard c4e329a98a90c591e219a394941369bbacaccfd2

如下：

发现test.a文件也变为1.8M了，这里值得提醒的是，由于LFS默认只下载了最新版本的test.a文件到本地仓库，因此这里在切到第二个版本时，实际上会自动去请求下载LFS管理的该test.a对应版本内容,不信你在切换之前把网络关闭会发现报错：

 

报连接失败，没网的255错误。

 

同理，切到第一次提交版本，test.a文件大小为5.2M。

 

当我们把三个版本都切过后，这个时候你把网络关闭模拟与远端断开连接，然后再次切到最新的第三版本，你会发现很快就切过去了不会再次发起请求拉取该版本下的test.a文件了，这是因为之前已经下载过了，由此可以总结：LFS默认会克隆最新的版本到本地而不克隆之前的老版本，如果需要相应的旧版本，只需要将Git切到相应版本即可，如果本地还没有该版本对应的LFS对象,Git就会去远端下载该版本文件，如果有了则不用再去下载。

 

 

1. 配置GIT_LFS_SKIP_SMUDEGE=1,不下载LFS管理文件。

重新新建一个目录，终端进入到该目录下，执行git lfs install（一定要记得先执行这句，不然对于GIT_LFS_SKIP_SMUDEGE=1,命令会不起作用）

在终端输入：GIT_LFS_SKIP_SMUDEGE=1 git clone git@code.paic.com.cn:haoshifu/test_gitlfs.git,将仓库克隆到本地,打开文件夹查看下test.a的大小：

 

你会惊奇地发现，这次test.a大小不是三个版本中的任何一个,而是131字节，用记事本打开查看内容:

version https://git-lfs.github.com/spec/v1

oid sha256:659315330f4214f81da86928dc3ecb8a526b95e9b2b634199682cea31c80a74b

size 555152

发现是有个链接、哈希值、大小，这是因为我们不下载LFS任何文件，因此Git LFS只将存储在Git仓库的那份该文件的指针文件给我克隆下来，而真正的数据文本并没有克隆。

不过不用担心，GIT LFS允许我们后面按“需”下载该文件对应版本，只需要在终端配置下单独下载该文件即可(当然你也可以配置匹配一类文件下载或更多),如下:

待完成后再次查看test.a文件大小:

test.a大小为555kb,说明已经获取了版本3的数据文件。之后操作就与（1）是一样的了。

 

 

结语:   通过这两章的探索学习，对Git的存储管理有了基本的认识，基本了解了Git是如何管理文件版本的，也明白了Git LFS是如何简化我们本地代码库的, 相信你也认识到了Git FLS大文件管理使用得当将提高我们的代码管理效率。