Git作为世界上最优秀的分布式版本控制工具，也是优秀的文件管理工具，它赋予了项目成员对项目进行远程协同开发能力，因此受到越来越多的行业从业人员的喜爱。很多优秀的项目管理平台，比如国内的Gitee，国外的Github，也都是以Git为核心操作。但是有些用户，尤其是游戏行业以及媒体行业人员可能会遇到一个问题，那就是随着提交的文件越来越多，项目越来越大，Git的响应速度越来越慢，更烦人的是，在提交到远程仓库的最后一刻，系统可能会提示用户此次提交被拒绝，原因是提交的文件太大，触发平台额度限制(无论是哪个平台)，相信很多人在这一刻是崩溃的。
那么该如何避免这种崩溃事件的发生呢？
下面就介绍今天的主角Git LFS(Git Large File Storage)，即Git大文件存储技术。
在Git仓库中，对于非文本文件，如各种多媒体文件，软件制品文件，二进制文件等等，这些文件往往体积比较大，使用Git直接管理会导致仓库的体积迅速膨胀，进而导致Git的许多操作变慢，同时也影响仓库上传到远程端。
Git LFS相当于Git的一种插件式增强工具，简单讲，它是在Git仓库使用这些文件的 指针代替 实际文件，而把实际文件存储在远程端LFS服务器，同时在本地仓库中实时追踪这些文件的变动。
原理
根据 Git LFS 官方帮助文档描述：
Git LFS是基于Git的 .gitattributs 配置文件的特性，用 smudge过滤器基于 指针文件寻找大文件内容， 用 clean过滤器在对大文件改动时，创建指针文件的新版本。同时还用 pre-push钩子将大文件上传到Git LFS服务器， 即在 git-push时， 如果提交中包含被LFS跟踪的大文件，pre-push钩子会检测到，并执行上传Git LFS服务器的动作。
因此，如果一个仓库中包含LFS内容，但是在推送时不想推送这类文件，只要加上 --no-verify选项就行，即：
$ git push --no-verify
--no-verify选项告诉 git push完全跳过 pre-push钩子。
前面提到被LFS管理的文件，本地仓库中保存的内容实际上是指针文件，其格式类似于下面这样：
$ git show HEAD:2.svg
version https://git-lfs.github.com/spec/v1
oid sha256:158213f90f8b27012034c6f58db63e1861b12aa122d98910de311bf1cb1e50a0
size 14651
(END)
version表示LFS的版本
oid表示文件对象的唯一hash值
size表示文件的大小
使用场景
场景一：
有一天你在Gitee上寻找感兴趣的项目，很快你就找到一个有价值的游戏项目，并且决定马上fork并clone下来：
$ git clone git@gitee.com:hightest/lfs-demo.git my-project
Cloning into 'lfs-copy'...
Enter passphrase for key '/home/git/.ssh/id_ed25519':
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 24 (delta 7), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (24/24), done.
Resolving deltas: 100% (7/7), done.
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Updating files: 100% (9/9), done.
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Filtering content: 100% (5/5), 1.51 MiB | 257.00 KiB/s, done.
你只是稍微修改了一个示例文件example.lfs，然后顺便git diff一下，看下修改变化:
$cd my-project
# edit example.lfs
$ git diff
diff --git a/example.lfs b/example.lfs
index 9550b5b..8bfca2b 100644
--- a/example.lfs
+++ b/example.lfs
@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
-oid sha256:fa3b58d0150ccbaed40ab94fd5574ae8225e83117c076b586ef08ff38be8d923
-size 69
+oid sha256:d8f84506d6b9e804852c3b15b921893606b4c2cbe388d1cc118bd42101eed2a8
+size 63
(END)
git diff显示的修改变动不是你期望的，为啥会出现这个差异呢？
如果你看过前面的原理部分，那你马上就能看明白，这是LFS指针文件的差异，这说明你下载的这个仓库是用了LFS来管理了文件。
此时仓库的实际存储的文件大小只有132 Bytes, 而它的实际大小是9.18 MiB, 大小相差几个数量级。
这样做的好处非常明显，对于很大的文件，可以只用很小的空间来管理它。
场景二：
作为一名游戏开发人员，你一直想设计开发一款好玩的游戏，场景一中使用的项目给了你灵感，你决定在这个基础上进行深度开发，你在这个仓库里面加入了很多图片文件，音效文件等游戏资源文件，开始每次git add/commit/push都很顺利，但有一次你把这些文件打包成 biger.zip，想一次推送到远程仓库，结果最后推送失败，系统提示如下：
$ git push origin master
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs.https://gitee.com/hightest/lfs-demo.git/info/lfs.locksverify true
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 6 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 388.92 MiB | 928.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.1]
remote: error: File: bcd245bbd11e6b1d71b5d3073f57007c4c002c4a 388.97 MB, exceeds 300.00 MB.
remote: Use command below to see the filename:
remote: git rev-list --objects --all | grep bcd245bbd11e6b1d71b5d3073f57007c4c002c4a
remote: Please remove the file from history and try again. (https://gitee.com/help/articles/4232)
To gitee.com:hightest/lfs-demo.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'gitee.com:hightest/lfs-demo.git'
很明显，由于推送的单个文件太大，超过配额300 MB，所以推送被拒绝。
同时，也能明显感觉得到，Git的各种基本操作变得卡顿、延迟。
这个时候，根据场景一的启发，你想到可以使用Gtiee的LFS服务，将大文件使用LFS管理，而仓库只保存它的指针信息，就能避免此问题。
- 使用LFS管理历史大文件：
如果一个仓库中原来已经提交了一些大文件，此时即使运行 git lfs track也不会有效的。
为了将仓库中现存的大文件应用到LFS，需要用 git lfs migrate导入到LFS中：
$ git lfs migrate import --include-ref=master --include="biger.zip"
migrate: override changes in your working copy? All uncommitted changes will be lost! [y/N] y
migrate: changes in your working copy will be overridden ...
migrate: Sorting commits: ..., done.
migrate: Rewriting commits: 100% (11/11), done.
master f9be3c554e9010ea5e0e23a6a0c6e53dca6c23b0 -> 53d5e655fe7cfd985f75384b92ac5414ad2ff394
migrate: Updating refs: ..., done.
migrate: checkout: ..., done.
–include-ref 选项指定导入的分支
如果向应用到所有分支，则使用–everything选项
–include 选项指定要导入的文件。可以使用通配符，批量导入。
上述操作会改写提交历史，如果不想改写历史，则使用 --no-rewrite选项，并提供新的commit信息：
$ git lfs migrate import --no-rewrite -m "lfs import"
将本地历史提交中的文件纳入到LFS管理后，如果重改了历史，再次推送代码时，需要使用强制推送。
这里选择改变提交历史，所以还需要使用 --force强制推送：
$ git push origin master --force
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs.https://gitee.com/hightest/lfs-demo.git/info/lfs.locksverify true
Uploading LFS objects: 100% (8/8), 419 MB | 0 B/s, done.
Enumerating objects: 38, done.
Counting objects: 100% (38/38), done.
Delta compression using up to 6 threads
Compressing objects: 100% (37/37), done.
Writing objects: 100% (38/38), 136.26 MiB | 943.00 KiB/s, done.
Total 38 (delta 12), reused 10 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.1]
To gitee.com:hightest/lfs-demo.git
+ cefd169...53d5e65 master -> master (forced update)
至此，已经将历史提交中的大文件迁移到远程LFS服务器，本地Git仓库，只保留这个大文件的指针文件，所以推送也不会再触发额度限制。推送成功之后，远程仓库就与本地保存一致，如场景一中的图示，它只管理这个大文件的指针文件。
推送成功后在仓库管理页面可以看到:
这里显示的是LFS Server实际管理的文件的大小，而Git仓库管理的大小则为134 Bytes!
场景三：
作为Git重度使用者的你，日常工作中必须使用Git管理你的文件，但是经历过上面对历史提交重写，并上传LFS服务器的你，学会了一开始在仓库中配置LFS功能，保证每一次提交、推送都保持完美。
在一个新的项目中，在初始阶段，你已经配置好了LFS。此时有更大一个文件 biggerthanbigger.zip，大小是778M，远远超过单个文件大小限制。
- 使用LFS管理新增大文件
$ cd new-project
$ git add biggerthanbigger.zip
$ git commit -m "add bigger than bigger zip file"
然后提交到远程仓库， 因为使用了LFS服务，如果不出意外，这次不会被拒绝。
$ git push origin master
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs.https://gitee.com/hightest/new-project.git/info/lfs.locksverify true
Uploading LFS objects: 100% (3/3), 1.2 MB | 0 B/s, done.
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 6 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 1.56 KiB | 1.56 MiB/s, done.
Total 10 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.1]
To gitee.com:hightest/new-project.git
dfe8b09..5f03bab master -> master
但实际上，意外是很可能发生的！
因为推送的文件过于大，很有可能因为超过LFS的配额而推送失败，虽然LFS是专门用来管理大文件的，但是也不能无限制存放大文件，毕竟这不是网盘。