通过这系列的前六篇文章，我们已经学会使用Git来对文本文件进行版本控制的管理。我们不禁要问，还有二进制文件呢，也可进行进行版本控制吗？答案是肯定的，Git已经有了可以处理像多媒体文件这样的二进制大对象块（blob）的扩展。因此，今天我们会学习使用Git来管理所谓的二进制资产。
似乎大家都认可的事就是Git对于大的二进制对象文件支持得不好。要记住，二进制大对象与大文本文件是不同的。虽然Git对大型的文本文件版本控制毫无问题，但是对于不透明的二进制文件起不了多大作用，只能把它当作一个大的实体黑盒来提交。
设想这样的场景，有一个另人兴奋的第一人称解密游戏，您正在为它制作复杂的3D建模，源文件是以二进制格式保存的，最后生成一个1GB大小的的文件。您提交过一次，在Git源仓库历史中有一个1GB大小的新增提交。随后，您修改了下模型人物的头发造型，然后提交更新，因为Git并不能把头发从头部及模型中其余的部分离开来，所以您只能又提交1GB的量。接着，您改变了模型的眼睛颜色，提交这部分更新：又是GB级的提交量。对一个模型的一些微小修改，就会导致三个GB级的提交量。对于想对一个游戏所有资源进行版本控制这样的规模，这是个严重的问题。
不同的是如obj这种格式的文本文件，和其它类型文件一样，都是一个提交就存储所有更新修改状态，不同的是obj文件是一系列描述模型的纯文本行。如果您修改了该模型并保存回obj文件，Git可以逐行读取这两个文件，然后创建一个差异版本，得到一个相当小的提交。模型越精细，提交就越小，这就是标准的Git用例。虽然文件本身很大，但Git使用覆盖或稀疏存储的方法来构建当前数据使用状态的完整描述。
然而，不是所有的都是纯文本的，但都要使用Git，所以需要解决方案，并且已经出现几个了。
OSTree开始是作为GNOME项目出现的，旨在管理操作系统的二进制文件。它不适用于这里，所以我直接跳过。
Git大文件存储（LFS）是放在GitHub上的一个开源项目，是从git-media项目中分支出来的。git-media和git-annex是Git用于管理大文件的扩展。它们是对同一问题的两种不同的解决方案，各有优点。虽然它们都不是官方的项目，但在我看来，每个都有独到之处：
git-media是集中模式，有一个公共资产的存储库。你可以告诉git-media大文件需要存储的位置，是在硬盘、服务器还是在云存储服务器，项目中的每个用户都将该位置视为大型文件的中心主存储位置。git-annex侧重于分布模式。用户各自创建存储库，每个存储库都有一个存储大文件的本地目录git/annex。这些annex会定期同步，只要有需要，每个用户都可以访问到所有的资源。除非通过annex-cost特别配置，否则git-annex优先使用本地存储，再使用外部存储。对于这些，我已经在生产中使用了git-media和git-annex，那么下面会向你们概述其工作原理。
git-media
git-media是使用Ruby语言开发的，所以首先要安装gem（LCTT译注：Gem是基于Ruby的一些开发工具包）。安装说明在其网站上。想使用git-meida的用户都需要安装它，因为gem是跨平台的工具，所以在各平台都适用。
安装完git-media后，你需要设置一些Git的配置选项。在每台机器上只需要配置一次。
$gitconfigfilter.media.clean"git-mediafilter-clean"$gitconfigfilter.media.smudge"git-mediafilter-smudge"