如何使用 Git 管理二进制大对象

阅读

• 第 1 部分：什么是 Git？
• 第 2 部分：Git 入门
• 第 3 部分：创建您的第一个 Git 仓库
• 第 4 部分：如何在 Git 中恢复旧版本文件
• 第 5 部分：3 个 Git 图形化工具
• 第 6 部分：如何构建您自己的 Git 服务器
• 第 7 部分：如何使用 Git 管理二进制大对象

在本系列的前六篇文章中，我们学习了如何使用 Git 管理文本文件的版本控制。但是二进制文件呢？Git 具有用于处理二进制大对象（如多媒体文件）的扩展，因此今天我们将学习如何使用 Git 管理二进制资产。

每个人似乎都同意的一件事是，Git 不太适合大型二进制大对象。请记住，二进制大对象与大型文本文件不同；您可以在大型文本文件上使用 Git 而不会出现问题，但 Git 对不可穿透的二进制文件无能为力，只能将其视为一个大的实心黑匣子并按原样提交。

假设您有一个复杂的第一人称益智游戏的新 3D 模型，并将其以二进制格式保存，生成一个 1 GB 的文件。您 git commit 一次，向仓库的历史记录中添加了一个 GB。稍后，您给模型换了发型并提交了更新；Git 无法区分头发与头部或模型的其余部分，因此您刚刚提交了另一个 GB。然后您更改了模型的眼睛颜色并提交了那个小的更改：又一个 GB。对于一个模型进行了一些细微的临时更改，这就是 3GB。将其扩展到游戏中的所有资产，您就会遇到严重的问题。

将其与 .obj 格式的文本文件进行对比。一次提交存储所有内容，就像其他模型一样，但 .obj 文件是一系列描述模型顶点的纯文本行。如果您修改模型并将其保存回 .obj，Git 可以逐行读取这两个文件，创建更改差异，并处理相当小的提交。模型越精细，提交就越小，这是一个标准的 Git 用例。这是一个大文件，但它使用一种覆盖或稀疏存储方法来构建数据当前状态的完整图像。

但是，并非所有内容都以纯文本形式工作，而且现在每个人都想使用 Git。需要一个解决方案，并且已经出现了几个。

Git Large File Storage (LFS) 是 GitHub 的一个开源项目，最初是 git-media 的一个分支。Git-media 和 git-annex 是 Git 的扩展，旨在管理大型文件。它们是解决同一问题的两种不同方法，并且各有优势。这些不是项目本身的官方声明，但在我的经验中，每个项目的独特之处在于

• Git-annex 倾向于分布式模型；您和您的用户创建仓库，并且每个仓库都有一个本地 .git/annex 目录，用于存储大型文件。附件定期同步，以便所有用户根据需要可以使用所有资产。除非使用 annex-cost 另行配置，否则 git-annex 优先使用本地存储而不是异地存储。

• Git-portal 也是分布式的，并且像 Git-annex 一样可以选择同步到中心位置。它使用您可能已经安装的常用实用程序（特别是 Bash、Git、rsync）。

• Git-LFS 是集中式模型，用于存储常用资产的仓库。您告诉 Git-LFS 大型文件的存储位置，无论是硬盘驱动器、服务器还是云存储服务，并且您项目中的每个用户都将该位置视为大型资产的中央主位置。

git-portal

Git-portal 使用标准的 UNIX 工具（如 Bash、Git 本身以及可选的 rsync）为 Git 提供简化的 blob 管理。它将大型二进制文件复制到本地或远程存储，并将它们替换为您可以与项目文件的其余部分一起提交的符号链接。

Git-portal 的简单性是以有时需要更多手动操作为代价的（例如，它没有自动垃圾回收）。它非常适合需要管理通常不适合 Git 管理的大型文件，但又不想学习全新系统的用户。Git-portal 模仿 Git 本身，因此学习曲线很小。

您可以从 Gitlab 上的项目页面 Gitlab 安装 Git-portal。

所有 Git-portal 命令都镜像 Git 本身。要在项目中使用 Git-portal

$ git-portal init

要添加文件

$ git-portal add bigfile.png

一旦文件被“通过门户发送”（在项目的术语中），您与 Git 的交互与往常完全相同。您像往常一样添加文件，相对地忽略了其中一些文件实际上是指向 _portal 目录的符号链接。

_portal 目录中的所有内容（完全被 Git 忽略）都可以单独备份到您喜欢的任何类型的存储中，无论是 USB 驱动器还是远程服务器。由于 Git-portal 提供了一些 Git 钩子（由特定 Git 操作（如推送或拉取）触发的自动化脚本），您甚至可以设置一个特殊的 Git 远程条目，以便您的 _portal 目录与远程位置自动同步

$ git remote add _portal alice@myserver.com:/home/alice/umbrella.git/_portal

Git-portal 的优势在于它是一个简单且 Linux 原生的系统。凭借相当少的常用实用程序和只需记住的几个额外命令，您可以管理大型项目依赖项，甚至可以在协作者之间共享它们。Git-portal 已在媒体项目、独立视频游戏和游戏博客中使用，用于管理从小型启动画面图像到大型 PDF，再到更大的 3D 模型的所有内容。

git-annex

git-annex 具有稍微不同的工作流程，并且默认使用本地仓库，但基本思想是相同的。您应该能够从发行版的仓库安装 git-annex，或者您可以根据需要从网站获取它。与 git-media 一样，任何使用 git-annex 的用户都必须在其机器上安装它。

初始设置比 git-media 更简单。要在您的服务器上创建裸仓库，请运行以下命令，替换您自己的路径

$ git init --bare --shared /opt/jupiter.git

然后将其克隆到您的本地计算机上，并将其标记为 git-annex 位置

$ git clone seth@example.com:/opt/jupiter.clone 
Cloning into 'jupiter.clone'... warning: You appear to have cloned
an empty repository. Checking connectivity... done. 
$ git annex init "seth workstation" init seth workstation ok 

不是使用过滤器来识别媒体资产或大型文件，而是通过使用 git annex 命令来配置什么被归类为大型文件

$ git annex add bigblobfile.flac
add bigblobfile.flac (checksum) ok
(Recording state in Git...) 

提交照常完成

$ git commit -m 'added flac source for sound fx'

但是推送是不同的，因为 git annex 使用自己的分支来跟踪资产。您进行的第一次推送可能需要 -u 选项，具体取决于您如何管理仓库

$ git push -u origin master git-annex 
To seth@example.com:/opt/jupiter.git 
* [new branch] master -> master 
* [new branch] git-annex -> git-annex 

与 git-media 一样，正常的 git push *不会* 将您的资产复制到服务器，它只会发送有关媒体的信息。当您准备好与团队的其余成员共享您的资产时，请运行 sync 命令

$ git annex sync --content

如果其他人已将资产共享到服务器，并且您需要拉取它们，则 git annex sync 将提示您的本地检出拉取您的机器上不存在但服务器上存在的资产。

Git annex 是一个经过微调的解决方案，灵活且用户友好。它强大且经过良好测试。

git-lfs

git-lfs 是用 Go 编写的，您可以从源代码或可下载的二进制文件安装它。说明位于 网站上。每个想要使用 git-lfs 的用户都需要安装它，但它是跨平台的，因此通常不会造成问题。

安装 git-lfs 后，您可以设置要 Git 忽略并由 Git-LFS 管理的文件类型。例如，要让 Git-LFS 跟踪所有 .png 文件

$ git lfs track "*.png"

每当您为 Git-LFS 跟踪添加文件类型时，都必须添加然后提交文件 .gitattributes

$ git add .gitattributes
$ git commit -m "LFS track *.png"

当您暂存这些类型的文件时，该文件将复制到 .git/lfs。

Git-LFS 是 Github 的一个项目，并且与 Github 的基础设施紧密相关。如果您想运行允许 Git-LFS 集成的 Git 服务器，您可以研究 Git-LFS 服务器规范（也是用 Go 编写的）并实现 API。

git-portal 和 git-annex 都很灵活，可以使用本地仓库而不是服务器，因此它们对于管理私有本地项目也同样有用。

大型文件和 Git

虽然 Git 是为文本文件设计的，但这并不意味着仅仅因为您有二进制资产就不能使用它。有很多很好的解决方案可以帮助您管理大型文件。如果您想使用 Git，那么真的没有太多借口不使用它，所以今天就试试吧！