使用Git管理大型二进制文件

我正在寻找有关如何处理源代码（Web应用程序）所依赖的大型二进制文件的意见。我们目前正在讨论几种替代方法：

1. 手动复制二进制文件。
   • 优点：不确定。
   • 相反：我强烈反对这一点，因为它在建立新站点/迁移旧站点时增加了出错的可能性。建立另一个障碍。
2. 用Git管理它们。
   • 专业版：消除了“忘记”复制重要文件的可能性
   • 相反：膨胀存储库并降低管理代码库的灵活性，而检出，克隆等将花费相当长的时间。
3. 单独的存储库。
   • 优点：签出/克隆源代码比以往任何时候都快，并且图像已正确存储在其自己的存储库中。
   • 相反：消除了在项目上拥有唯一的 Git存储库的简单性。它肯定会引入其他我从未想过的东西。

您对此有何经验/想法？

另外：是否有人在多个Git存储库中进行过管理并在一个项目中进行管理？

这些文件是程序的图像，该程序会在其中生成包含这些文件的PDF。文件不会经常更改（像几年一样），但是它们与程序非常相关。没有文件，该程序将无法运行。

如果程序如果没有这些文件就无法运行，则将它们拆分成一个单独的存储库似乎是个坏主意。我们有大型测试套件，可以分成单独的存储库，但它们确实是“辅助”文件。

但是，您也许可以在单独的存储库中管理文件，然后git-submodule以理智的方式将其拉入项目。因此，您仍然拥有所有来源的完整历史记录，但是据我了解，您只会拥有图像子模块的一个相关修订版。该git-submodule工具应帮助您使正确的代码版本与映像的正确版本保持一致。

这是对 Git Book 中子模块的很好介绍。

我最近发现git-annex，发现它很棒。它旨在有效地管理大型文件。我将其用于照片/音乐（等）收藏。git-annex的开发非常活跃。可以从Git存储库中删除文件的内容，Git只能跟踪树层次结构（通过符号链接）。但是，要获取文件的内容，在拉/推之后需要执行第二步，例如：

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

有许多可用命令，并且网站上有大量文档。Debian提供了一个软件包。

自2015年4月以来的另一种解决方案是Git大文件存储（LFS）（由GitHub提供）。

它使用git-lfs（请参阅git-lfs.github.com）并在支持它的服务器上进行了测试：lfs-test-server：
您只能将元数据存储在git repo中，而大文件则可以存储在其他位置。

看看git bup，这是一个Git扩展，可以在Git存储库中智能地存储大型二进制文件。

您希望将其作为子模块，但不必担心存储库变得难以处理。他们的示例用例之一是将VM映像存储在Git中。

我实际上并没有看到更好的压缩率，但是我的存储库中没有太大的二进制文件。

你的旅费可能会改变。

您也可以使用git-fat。我喜欢它仅取决于Python和rsync。它还通过以下自我说明命令来支持通常的Git工作流程：

git fat init
git fat push
git fat pull

此外，您需要将.gitfat文件检入到存储库中，并修改.gitattributes以指定要git fat管理的文件扩展名。

您可以使用normal添加二进制文件git add，它会git fat根据gitattributes规则进行调用。

最后，它的优点是可以在存储库和用户之间共享实际存储二进制文件的位置，并支持任何rsync功能。

更新：如果您使用的是Git-SVN桥，请不要使用git-fat。最终将从Subversion存储库中删除二进制文件。但是，如果您使用的是纯Git存储库，那么它的运行效果很好。

我将使用子模块（如Pat Notz）或两个不同的存储库。如果您经常修改二进制文件，那么我将尽量减少清理历史记录的巨大存储库的影响：

几个月前，我遇到了一个非常类似的问题：大约21 GB的MP3文件，未分类（名称错误，id3错误，不知道我是否喜欢该MP3文件...），并在三台计算机上复制了。

我在主Git存储库中使用了外部硬盘驱动器，并将其克隆到每台计算机中。然后，我开始按惯常方式对它们进行分类（推，拉，合并...删除和重命名多次）。

最后，我在.git目录中只有〜6 GB的MP3文件和〜83 GB。我使用git-write-tree并git-commit-tree创建了一个没有提交祖先的新提交，并启动了一个指向该提交的新分支。该分支的“ git log”仅显示一次提交。

然后，我删除了旧分支，仅保留了新分支，删除了引用日志，然后运行“ git prune”：之后，我的.git文件夹的权重仅为〜6 GB。

您可以不时以相同的方式“清除”大型存储库：“ git clone”的存储库将更快。

我想提出的解决方案基于孤立分支和对标记机制的轻微滥用，因此被称为*孤立标记二进制存储（OTABS）

TL; DR 12-01-2017如果可以使用github的LFS或其他第三方，则应该使用。如果不能，请继续阅读。请注意，此解决方案是骇客，应这样对待。

OTABS的理想特性

• 它是一个纯git和仅git的解决方案-无需任何第三方软件（如git-annex）或第三方软件（如github的LFS）即可完成工作。
• 它有效地存储二进制文件，即不会使存储库的历史膨胀。
• git pull和git fetch（包括）git fetch --all仍然具有较高的带宽效率，即默认情况下并非所有大型二进制文件都从远程提取。
• 它可以在Windows上运行。
• 它将所有内容存储在一个git仓库中。
• 它允许删除过时的二进制文件（与bup不同）。

OTABS的不良特性

• 它git clone可能会导致效率低下（但不一定取决于您的用法）。如果部署此解决方案，则可能必须建议您的同事使用git clone -b master --single-branch <url>而不是git clone。这是因为git clone默认会从字面上克隆整个存储库，包括通常不希望浪费带宽的内容，例如未引用的提交。取自SO 4811434。
• 它使git fetch <remote> --tags带宽效率低下，但不一定使存储效率低下。您可以随时建议您的同事不要使用它。
• 您将git gc不得不定期使用技巧来从不需要的文件中清除存储库。
• 它不如bup或git-bigfiles高效。但这分别更适合您要尝试的工作和更现成的。您可能会遇到成千上万个小文件或千兆字节范围内的文件的麻烦，但请继续阅读以获取解决方法。

添加二进制文件

在开始之前，请确保已提交所有更改，工作树是最新的，并且索引中不包含任何未提交的更改。最好将所有本地分支推送到远程（github等），以防万一发生灾难。

1. 创建一个新的孤立分支。git checkout --orphan binaryStuff会成功的 这将产生一个与其他分支完全断开连接的分支，并且您将在该分支中进行的第一个提交将没有父项，这将使其成为根提交。
2. 使用清理索引git rm --cached * .gitignore。
3. 深吸一口气，然后使用删除整个工作树rm -fr * .gitignore。内部.git目录将保持不变，因为*通配符与之不匹配。
4. 复制到您的VeryBigBinary.exe或VeryHeavyDirectory /中。
5. 添加并提交。
6. 现在，它变得很棘手-如果将它作为一个分支推送到远程，则所有开发人员在下次调用git fetch其阻塞连接时都将下载它。您可以通过推送标签而不是分支来避免这种情况。如果他们有键入的习惯，这仍然会影响您同事的带宽和文件系统存储git fetch <remote> --tags，但请继续阅读以寻求解决方法。来吧git tag 1.0.0bin
7. 推送您的孤儿标签git push <remote> 1.0.0bin。
8. 这样一来，您就永远不会偶然推送二进制分支，可以将其删除git branch -D binaryStuff。您的提交不会被标记为垃圾回收，因为指向它的孤立标记1.0.0bin足以使其存活。

签出二进制文件

1. 我（或我的同事）如何将VeryBigBinary.exe检出到当前工作树中？例如，如果您当前的工作分支是master，则可以简单地进行git checkout 1.0.0bin -- VeryBigBinary.exe。
2. 如果您没有1.0.0bin下载孤儿标签，则将失败，在这种情况下，您必须git fetch <remote> 1.0.0bin事先下载。
3. 您可以将添加VeryBigBinary.exe到您的主目录中.gitignore，这样您的团队中就不会有人偶然使用二进制文件污染项目的主要历史记录。

完全删除二进制文件

如果您决定从本地存储库，远程存储库和同事的存储库中完全清除VeryBigBinary.exe，则可以：

1. 删除遥控器上的孤立标签 git push <remote> :refs/tags/1.0.0bin
2. 本地删除孤立标记（删除所有其他未引用的标记）git tag -l | xargs git tag -d && git fetch --tags。取自SO 1841341，稍作修改。
3. 使用git gc技巧在本地删除您现在未引用的提交。git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@"。它还将删除所有其他未引用的提交。取自SO 1904860
4. 如果可能，请在遥控器上重复git gc技巧。如果您是自托管存储库，则可能是这样，而某些git提供程序（例如github）或某些公司环境中可能无法实现。如果您使用的服务提供商托管的ssh不能使您远程访问ssh，请放手。您的提供商的基础结构可能会在自己的美好时光中清理未引用的提交。如果您在公司环境中，则可以建议IT部门执行cron作业垃圾回收，每周大约一次。只要您建议您的同事始终使用，git clone -b master --single-branch <url>而不管它们是否在带宽和存储方面都不会对您的团队产生任何影响git clone。
5. 您所有想摆脱过时的孤儿标签的同事都只需执行步骤2-3。
6. 然后，您可以重复添加二进制文件以创建新的孤立标记的步骤1-8 2.0.0bin。如果您担心同事打字git fetch <remote> --tags，实际上可以重新命名1.0.0bin。这将确保下次他们获取所有标签时，旧标签1.0.0bin将不被引用并标记为后续垃圾回收（使用步骤3）。当您尝试覆盖遥控器上的标签时，您必须-f像这样使用：git push -f <remote> <tagname>

后记

• OTABS不会影响您的母版或任何其他源代码/开发分支。提交哈希，所有历史记录以及这些分支的较小大小均不受影响。如果您已经用二进制文件充实了源代码历史记录，则必须将其清理为单独的工作。该脚本可能有用。

• 确认可以在Windows上使用git-bash使用。

• 最好应用一组标准度量标准，以使二进制文件的存储效率更高。频繁运行git gc（不带任何其他参数）使git通过使用二进制增量优化文件的基础存储。但是，如果您的文件不太可能在提交与提交之间保持相似，则可以完全关闭二进制增量。此外，由于压缩已压缩或加密的文件（如.zip，.jpg或.crypt）没有意义，因此git允许您关闭基础存储的压缩。不幸的是，这是一个全有或全无的设置，也会影响您的源代码。

• 您可能需要脚本化OTABS的各个部分，以便更快地使用。特别是，从将二进制文件完全删除到updategit挂钩中的脚本步骤2-3 可以为git fetch（“获取并删除所有过期的内容”）提供引人注目的但可能是危险的语义。

• 您可能要跳过“ 完全删除二进制文件”的第4步，以将所有二进制更改的完整历史记录保留在远程计算机上，而这要付出中央存储库膨胀的代价。随着时间的流逝，本地存储库将保持精简。

• 在Java世界中，可以将此解决方案与结合使用，maven --offline以创建可复制的脱机版本，该版本完全存储在您的版本控件中（使用Maven比使用gradle容易）。在Golang世界中，可以用此解决方案来管理GOPATH而不是go get。在python世界中，可以将其与virtualenv结合使用以产生一个自包含的开发环境，而无需依赖PyPi服务器进行任何从头开始的构建。

• 如果您的二进制文件经常改变，像构建工件，这可能是一个好主意，脚本解决方案，它存储了文物5个最新版本的孤儿标签monday_bin，tuesday_bin...，friday_bin和也是一个孤儿标签为每个版本1.7.8bin 2.0.0bin等等。您可以weekday_bin每天旋转和删除旧的二进制文件。这样，您可以充分利用两个世界：保留源代码的整个历史记录，但仅保留二进制依赖项的相关历史记录。获取给定标签的二进制文件也很容易，而无需获取所有带有其所有历史记录的源代码：git init && git remote add <name> <url> && git fetch <name> <tag>应该为您完成。

我认为，如果您可能经常修改这些大文件，或者打算大量修改git clone或git checkout，那么您应该认真考虑使用另一个Git存储库（或者也许是另一种访问这些文件的方式）。

但是，如果您像我们一样工作，并且您的二进制文件不经常修改，那么第一次克隆/签出将很长，但是之后它应该和您想要的一样快（考虑到用户继续使用第一个克隆存储库，他们会有）。

SVN似乎比Git更有效地处理二进制增量。

我必须决定用于文档的版本控制系统（JPEG文件，PDF文件和.odt文件）。我刚刚测试了添加JPEG文件并将其旋转90度四次（以检查二进制增量的有效性）。Git的存储库增长了400％。SVN的存储库仅增长了11％。

因此，看起来SVN与二进制文件相比效率更高。

因此，我的选择是对源代码使用Git，对文档等二进制文件使用SVN。

git clone --filter 来自Git 2.19 +浅层克隆

如果Git和GitHub开发人员并使它对用户足够友好（例如，对于子模块来说，他们可能还没有实现），那么这个新选项最终可能成为二进制文件问题的最终解决方案。

它实际上只允许获取服务器所需的文件和目录，并且是与远程协议扩展一起引入的。

这样，我们可以先进行浅表克隆，然后针对每种类型的构建，自动使用构建系统获取哪些Blob。

甚至已经有一个--filter=blob:limit<size>允许限制最大blob大小来获取。

我提供了一个功能最少的详细示例：如何仅克隆Git存储库的子目录？

我正在寻找有关如何处理源代码（Web应用程序）所依赖的大型二进制文件的意见。您对此有何经验/想法？

一旦我的Web应用程序二进制数据的缺口超过3 GB，我个人就遇到了Git与某些云主机的同步失败。当时我考虑过BFT Repo Cleaner，但感觉就像是黑客。从那时起，我就开始将文件保留在Git权限范围之外，而是利用诸如Amazon S3之类的专用工具来管理文件，版本控制和备份。

是否有人在多个Git存储库中进行过管理并在一个项目中进行管理？

是。雨果主题主要通过这种方式进行管理。这有点笨拙，但可以完成工作。

我的建议是为工作选择合适的工具。如果是公司用，并且您要在GitHub上管理代码行，请付钱并使用Gi​​t-LFS。否则，您可以探索更多创造性的选择，例如使用区块链进行分散式加密文件存储。

要考虑的其他选项包括Minio和s3cmd。

看一下 camlistore。它不是真正基于Git的，但是我发现它更适合您的工作。