我现在开始使用git作为我的版本控制系统，但我做了一些网页/游戏开发，当然需要存储图像（二进制数据）。因此，如果我的理解是正确的，如果我提交了一个图像并且它改变了100次，如果我获取该repo的新副本，我基本上会检查该二进制文件的所有100个修订版本？
这不是一个大型回购的问题，其中图像定期更改不会最初获取回购最终变得非常大吗？在现实世界中有没有人遇到过这个问题？我已经看到了一些替代方案，例如，使用子模块并将图像保存在单独的仓库中，但这只会使代码库更小，图像仓库仍然很大。基本上我只是想知道是否有一个很好的解决方案。
答案 0 :(得分：7)
我不会称之为“结帐”，但是，是的，第一次获取存储库时，如果二进制数据巨大且不可压缩，它将会是什么样的 - 巨大的。是的，因为保护法仍然有效地将其分解为模块将不会为初始拉动存储库节省空间和时间。
一个可能的解决方案是在拉动它时仍然使用单独的存储库和--depth选项。浅的存储库有一些限制，但我不记得究竟是什么，因为我从未使用它。检查文档。关键字是“浅层”。
修改：来自git-clone(1)：
浅的存储库有很多 限制（您无法克隆或获取 从它，也不是推进或推入它，）， 但如果你是这样的话就足够了 对近期的历史感兴趣 历史悠久的大型项目 我想发送补丁作为 补丁。
答案 1 :(得分：3)
我所做的是使图像被忽略/未跟踪目录，然后使用其他非git系统同步图像目录/目录（或者当你谈论很多图像时，只需手动复制图像目录一次更改你不需要保持完全同步）。
答案 2 :(得分：2)
不幸的是，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/）。
我建议试用它但将二进制文件与代码分开（即使用子模块）。在这种情况下，如果它不适合您，您可以使用其他解决方案，而无需重写主存储库的整个历史记录。
答案 3 :(得分：1)
在这里讨论了使用GIT的大文件存储：http://blog.deveo.com/storing-large-binary-files-in-git-repositories/
作为我研究的一部分，我遇到了这个问题，我认为我会将人们指向我已经评论过的博客条目（扰乱警报，他们建议非Windows用户使用git-annex） 。 。