我已经使用git一段时间来进行源代码控制了，我真的很喜欢它。所以我开始调查使用git存储大量的二进制文件，我发现这不是git的一杯茶。那么大文本文件呢？似乎git应该处理那些就好了，但我也遇到了问题。
我正在使用550mb大小的mbox样式文本文件对此进行测试。我git init'ed新的回购做这件事。以下是我的结果：
因此，每次提交都会将邮箱文件的新副本添加到repo中。现在我想尝试将回购的大小降低到易于管理的程度。以下是我的结果：
我希望能够将回购的大小缩小到306mb左右，但我无法弄清楚如何。任何更大的东西似乎都存储了很多重复的数据。
我希望回购只会增加收到的新电子邮件的大小，而不会增加整个邮箱的大小。我不是试图在这里控制电子邮件版本，但这似乎是我使用夜间脚本逐步备份用户主目录的重大阻碍。
如何在将大量文本插入非常大的文本文件末尾时，如何防止回购邮件大小爆炸？
我看过bup和git附件，但如果可能的话，我真的很想坚持使用普通的旧git。
感谢您的帮助！
答案 0 :(得分：3)
我认为git不会在存储增量方面做得很好，即使你能够这样做，它也不会是确定性的。也就是说，根据http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/，您可能需要尝试git repack -a -d --depth=250 --window=250。
我怀疑您最好的选择是使用git --rebase截断历史记录，并仅存储过去的几个备份。你可以使用git分支来做到这一点。建立一个名为年度，月度和每日的分支机构。每天，每天提交，然后使用git rebase --onto HEAD~4 HEAD~3 daily删除超过3天的备份。在每周的第一天，每周结账和git cherry-pick daily，然后执行相同的git rebase删除超过3周的每周备份。最后，在每年的第一天，遵循类似的过程。您可能希望每次在此序列之后执行git gc，以释放旧空间。
但如果你这样做，你就不再利用git并且滥用它的工作方式相当多。我认为最好的备份解决方案不涉及git。
答案 1 :(得分：2)
Git不是最好的备份工具，但它应该能够非常有效地处理附加到文本文件。我怀疑你的结果。我在OS X上用354 meg文件和git 1.7.7重复了你的实验。这是我的行为和.git的大小。
正如你所看到的，git非常有效。 94兆是压缩mbox的大小。它不会变小。
我猜你使用的是旧版本的git，或者你的邮箱正在压缩或加密你的mbox文件。
答案 2 :(得分：1)
虽然在打包对象后看到的差异基于文件类型等，但git不是备份工具，不应该用于那种情况。如果你看一下git的整个哲学，它是基于磁盘空间便宜并且优化操作速度的假设。此外，无论文件类型是二进制文件还是文本文件，git都会以相同的方式存储它，当然，如上所述，文件类型将决定打包后您看到的差异。只有出于差异和其他目的，git才能区分二进制文件和文本文件，而不是用于存储。
使用适当的备份工具，这也将节省您的磁盘空间。像ZFS备份这样的东西值得一试：https://svn.oss.prd/repos/SHAW/BuildAndReleaseTransition/TeamCity/TeamCityConfiguration-39/TeamCityConfiguration.docx
答案 3 :(得分：1)
大文件的一个副作用是git diff内存不足。
虽然Git不是正确的工具（如其他答案中所述），但至少{g} 2。0（2014年第4季度）会解决git diff问题。
请参阅commit 6bf3b81中的Nguyễn Thái Ngọc Duy (pclouds)：
diff --stat：标记任何大于core.bigfilethreshold二进制文件太大可能导致无法分配内存 如果它发生在这里，它可能会影响相当多的涉及差异的命令 此外，太大的文件无论如何都无法进行比较（很可能是非文本），因此请将它们标记为二进制并跳过查看其内容。