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

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

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

您对此有何经验/想法？

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

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

#1楼

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

git fat init
git fat push
git fat pull

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

您可以使用普通的git add添加二进制文件，后者又会根据您的gitattributes规则调用git fat 。

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

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

#2楼

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

#3楼

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

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

#4楼

我想提出的解决方案基于孤立分支和对标记机制的轻微滥用，此后称为*孤立标记二进制存储（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等），以防万一发生灾难。

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

签出二进制文件

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

完全删除二进制文件

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

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

后记

OTABS不会影响您的母版或任何其他源代码/开发分支。提交哈希，所有历史记录以及这些分支的较小大小均不受影响。如果您已经用二进制文件充实了源代码历史记录，则必须将其清理为单独的工作。该脚本可能有用。
确认可以在Windows上使用git-bash使用。
最好应用一组标准度量标准，以使二进制文件的存储效率更高。频繁运行git gc （没有任何其他参数）使git通过使用二进制增量来优化文件的基础存储。但是，如果文件从提交到提交的可能性不大，则可以完全关闭二进制增量。此外，由于压缩无用的压缩或加密文件（如.zip，.jpg或.crypt）是没有意义的，因此git允许您关闭基础存储的压缩。不幸的是，这是一个全有或全无的设置，也会影响您的源代码。
您可能需要脚本化OTABS的各个部分，以便更快地使用。特别地，从完全删除二进制文件到update git钩子的脚本步骤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>应该为您完成。