Git LFS 支持大文件存储

出于好意：设计团队开始把他们大尺寸的图形文件添加到你的项目仓库当中，然而引起的结果是，你看着仓库不断增大直到数 GB 大小……

在 GIT 中以二进制文件来运行确实是一种明智的做法，每当提交一个 100MB 的 Photoshop 文件中的细微改变，你仓库的大小当然也会增长 100MB，这样快速的增长会使你的仓库因为内容太过于庞大而变得几乎无法使用。它确实与所有”大”文件有关：如视频，音频记录，数据集等的问题。

但是，如果说不使用版本控制你的设计/概念/视频/音频/可执行文件/工作也不能解决问题（知识库过大）。一般来说，版本控制的好处还是存在的，而且应该用于各种各样的项目当中去。

幸运的是，这有一个 GIT 扩展可以让使用大型文件更加有效率，跟“Large File Storage”（或者叫”LFS”,如果你喜欢这个简称）问个好吧。

---

使用 LFS : 有效的处理大文件

当然，LFS 并不能像”变魔术一样”处理所有的大型数据：它需要记录并保存每一个变化。然而，这就把负担转移给了远程服务器 - 允许本地仓库保持相对的精简。

为了实现这个可能，LFS 耍了一个小把戏：它在本地仓库中并不保留所有的文件版本，而是仅根据需要提供检出版本中必需的文件。

但这引发了一个有意思的问题：如果这些庞大的文件本身没有出现在你的本地仓库中….改用什么来代替呢? LFS 保存轻量级指针中有真实的文件数据。当你用一个这样的指针去迁出一个修订版时，LFS 会很轻易地找到源文件（不在他上面可能就在服务器上，特殊缓存）然后你下载就行了。

因此，你最终只会得到你真正想要的文件 - 而不是一些你可能永远都不需要冗余数据。

特性
- 大文件存储：支持Git中几GB大小的文件；
- 仓库空间足：Git仓库很足，可很好的管理外部文件；
- 快速复制和提取：下载数据量较少，让复制和读取大文件更快；
- 一样的Git工作流：针对二级存储系统或工具集并未产生额外的指令
- 相同的接入控制和权限：针对Git仓库的大文件，远程主机和GitHub上拥有一样的接入控制和权限。

---

安装 LFS

LFS 尚未加入 Git 的核心二进制文件，但是它可以作为扩展使用。这意味着，使用之前我们需要提前安装。

• 服务端
  目前并不是所有主机服务器都支持 LFS。 但如果你是 GitLab/Github/Gitblit 用户就不必担心，它们已经支持LFS了! 您的管理员只需要开启LFS选项。

• 本地机器
  你本地安装的 Git 也需要支持 LFS。
  如果你使用 Tower/SourceTree，一个 Git 桌面客户端，你就不需要额外安装了，因为 Tower/SourceTree 已经非常好地支持 Git 大文件系统。

---

使用 LFS 追踪文件

SourceTree
有时候，你可能想知道到底有哪些文件在被 LFS 追踪。你可以简单的看看.gitattributes文件。然而，它们不是真实的文件，而是包含一些规则和理论的文件：某些文件可能会漏掉，例如由于拼写错误或者过分严格的规则。

---

尽早追踪

记住 LFS 并没有改变 git 本身的原理：被提交到仓库中的文件还会留在那儿。改变项目的提交历史很困难（也有风险）。

这意味着你应该在文件没有提交到仓库前就让 LFS 进行追踪。

不然，它就成了项目历史的一部分 - 令项目增大数 MB 或数 GB 的大小…

初始化仓库时要选择配置要追踪的文件规则的完美时机（就跟配置忽略文件一样）。