Git或SVN如何处理大型二进制文件

Question

我们的团队决定终于放弃Serena PVCS（耶！）现在我们需要在Git和SVN之间做出决策。但是，即使阅读了一些关于git如何处理二进制文件的过时文档和帖子，我仍然找不到有关此主题的直接答案。因此，由于我们的一个存储库有50GB，其中90％是.doc，.xls，.zip文件（每个版本从1.0到1.178大小介于1MB到20MB之间），我不确定是否要将我的船转向Git Island。

目前我找到的是：

https://help.github.com/articles/working-with-large-files

http://stevehanov.ca/blog/index.php?id=50

https://news.ycombinator.com/item?id=3548824

大多数我们的“极客”（最近出生的开发人员，不到1年的大学毕业）都在呼吁使用Git，因为它是“主流”，但我不认为Git会解决这种类型的仓库问题。我的意思是，我们已经使用Git管理了一些仓库（主要是Java源代码），但我正在努力决定我们应该朝哪个方向发展。

此外，除了Git / svn / Mercurial之外，是否有其他用于bin文件的选项？

提前致谢。

编辑：请理解我不会涉及{{link1：“gorila vs shark”}}哲学，我只是试图获得更多的输入，以便决定是否应该选择Git而不是svn。

- thclpr

---

从个人的角度来看（这就是为什么它不是一个答案），Git 对我来说大多数情况下胜出，因为你可以在本地工作并且很容易地将更改与主分支合并，大多数时候都是自动的。然而，考虑到你不能合并两个 .zip 文件的更改，并且将它们保留在本地会膨胀本地副本，我可能会选择 SVN。对我来说，省去所有针对二进制文件的 Git 扩展的麻烦也是一个加分项。 - Bartek Banachewicz

Answer 1

大部分“极客”其实并不是真正的极客，而是没有头脑的Git粉丝。完全忽略初学者，他们不能发表意见。

从个人经验来看，我可以得出结论：两个系统在处理大型二进制文件方面几乎同样平庸，SVN（对于1.7版本之前）略微有些优势（现在我完全没有在Git方面看到）。具体表现为：

- 同一修改的文件提交到仓库后，SVN仓库的大小比Git仓库略小。 - 我从未因大型文件破坏了SVN仓库，但对于Git而言，这种情况发生得相当明显。

对于你的情况，最好的选择是Mercurial，配合LargeFiles扩展（以及针对不同文件类型的特殊差异|合并|查看器，编码器|解码器是额外的奖励，Git|SVN无法提供）。

- Lazy Badger

---

我将您的答案标记为正确，因为它帮助我决定使用Mercurial。我还发现了这篇文章，必读 :)http://www.ericsink.com/entries/hg_denzel.html - thclpr

Answer 2

Git不太适合处理二进制文件，因为它无法对其进行有效压缩。这些文件会在Git存储库历史记录中占用大量空间。我亲身经历过这种情况；当我添加和删除几张小图片时，重新克隆存储库需要花费很长时间。

对于SVN而言，由于它是集中式的，对开发人员并没有太大影响，因为你通常不需要整个存储库的完整历史记录。至于服务器上占用的空间，我不太确定。

最好寻找一种替代方法来上传大型二进制文件，也许最好的方法是将文件上传到另一个来源。SVN应该可以很好地处理二进制文件。至于Git，请永远不要使用它处理二进制文件。如果必须这样做，请将二进制文件保留在单独的存储库中。

但由于你没有这样的需求，你应该使用SVN。

---

进一步阅读链接: Git和二进制数据

- wei2912

---

我发现这篇帖子非常有用。Git经过优化，可用于存储源代码文本。 - dot slash hack

Answer 3

你可以使用 git-lfs (Git Large File Storage) 来解决这个问题。

从上面链接的 git-lfs 页面中可以看到：

Git 大文件存储（LFS）用文本指针替换 Git 中的大文件，如音频样本、视频、数据集和图形，并将文件内容存储在远程服务器上...

- Rotareti