Git 和二进制数据答案

【问题标题】：Git and binary dataGit 和二进制数据
【发布时间】：2009-12-15 22:46:52
【问题描述】：

我目前开始将 git 用于我的版本控制系统，但是我做了一些网络/游戏开发，当然需要存储图像（二进制数据）。因此，如果我的理解是正确的，如果我提交了一个图像并且它更改了 100 次，那么如果我获取该 repo 的新副本，我基本上会检查该二进制文件的所有 100 个修订版？

这不是大型存储库的问题，其中图像定期更改，存储库的初始获取最终不会变得相当大吗？有人在现实世界中遇到过任何问题吗？例如，我已经看到了一些替代方案，使用子模块并将图像保存在单独的存储库中，但这只会使代码库更小，图像存储库仍然会很大。基本上我只是想知道是否有一个很好的解决方案。

【问题讨论】：

这是 git 的设计限制。编写它是为了做好一件事：管理 Linux 源代码树，这几乎都是纯文本。 Git 是关于差异和合并的，这些东西并不真正适用于图像。如果您的媒体文件非常大或经常编辑，您最好使用不同的机制来存储这些文件的历史记录，并且如果您没有真正在代码上协作或制作大量分支，那么您可能会更好完全不使用 git。
git 将处理二进制文件，它用于存储 deltas 的系统基于二进制内容（您在补丁中看到的文本差异是动态计算的，而不是存储内容的表示）。话虽如此，压缩图像的 xdelta 不太可能减少空间需求。您可以将所有图像保存为 XPM 或 BMP：p
如果您想要一个图像的 100 个版本，那么无论您使用哪种 VCS，您都必须在某处存储 100 个图像。如果您有一个 git 服务器，您可以将图像转储到服务器上，然后浅层克隆到较小的深度。如果您需要返回version0，那么当然，您需要下载整个存储库。

标签： git

【解决方案1】：

我不会称其为“结帐”，但是，是的，当您第一次获取存储库时，只要二进制数据巨大且不可压缩，它就会变成原来的样子 - 巨大。是的，因为守恒定律仍然有效，将其分解为模块不会在初始拉取存储库时为您节省空间和时间。

一个可能的解决方案是在拉取它时仍然使用单独的存储库和--depth 选项。浅存储库有一些限制，但我不记得具体是什么，因为我从未使用过它。检查文档。关键字是“浅”。

编辑：来自git-clone(1)：

浅层存储库有许多限制（您不能克隆或获取从它，既不推也不推），但如果你只是对最近的历史感兴趣历史悠久的大型项目，以及想发送修复为补丁。

【讨论】：

有趣的是，如果您考虑到上面的文档引用，几乎似乎非分布式 vcs 可能更适合二进制数据，因为无论如何在处理二进制数据时您都缺少使用 git 的许多优点.
是的，但是您可能仍然会忍受一次获取巨大存储库的痛苦。此外，您可以为二进制数据使用单独的非 git 存储库。但是因为我真的很喜欢 git（虽然一开始对它持怀疑态度——Linus 写的所有东西都会受到称赞），我建议分离二进制数据......好吧，单独处理它;-)

【解决方案2】：

我所做的是使图像被忽略/未跟踪的目录，然后使用其他非 git 系统同步图像目录/目录（或者当您谈论大量图像时，只需手动复制图像目录更改一次您不需要保持完全同步）。

【讨论】：

【解决方案3】：

不幸的是，git 并不是真正用于存储二进制数据的。因为它是分布式的，所以每当您克隆它时，您都会提取所有文件的所有版本。从代码存储库中删除那些大型二进制文件也变得非常困难。更多信息在这里：(http://www.somethingorothersoft.com/2009/09/08/the-definitive-step-by-step-guide-on-how-to-delete-a-directory-permanently-from-git-on-widnows-for-dumbasses-like-myself/)。

我建议试用它，但将二进制文件与代码分开（即使用子模块）。在这种情况下，如果它不适合您，您可以使用其他解决方案而无需重写主存储库的整个历史记录。

【讨论】：

【解决方案4】：

作为我研究的一部分，我遇到了这个 SO 问题，我认为我会将人们指向我已经审查过的博客条目（剧透警告，他们建议非 Windows 用户使用 git-annex）。 .

【讨论】：