GitHub 能够很好地处理大型代码仓库吗？

Question

3

我公司的SVN代码仓库在下载时大约为250MB。随着多年来的更改，它可能非常庞大（4倍于此大小）。如果我们将所有这些内容转移到GitHub，每个用户是需要下载250MB还是需要下载1GB或更多才能获取完整的仓库历史记录呢？

- Paul Mendoza

我的理解是，当你克隆一个Git仓库时，你只会得到当前的代码，而不会得到所有的历史记录。如果我理解有误，请纠正我。 - akonsu

2

@akonsu：不，你会得到整个仓库。 - nhahtdh

你可以获取整个代码库是 Git 的优势之一。 - Andy Lester

1

http://programmers.stackexchange.com/questions/148434/why-do-git-mercurial-repositories-use-less-space 可以提供帮助。 - VonC

3个回答

2

如果我们将所有内容转移到GitHub上，每个用户都需要下载250MB还是需要下载1GB或更多才能获取整个仓库的完整历史记录？

每个用户在首次克隆时都需要检索整个仓库。但是，git服务器端实现会将“压缩”版本的仓库作为packfile发送。因此，传输的数据重量要比1GB小得多。

每个后续的fetch/pull操作只会检索服务器知道的新git对象（Commits、Trees和Blobs），并且这些对象不在客户端本地仓库中。这些对象也会作为packfile发送到网络。

尽管@akonsu在陈述您可以克隆存储库的浅层版本（即没有整个历史记录）时是正确的，但这将阻止用户进一步与托管在GitHub上的主要上游存储库进行交互。

实际上，git clone文档说明：“浅层存储库有许多限制（您无法从中克隆或提取，也无法推送到其中或从其中推送）”。

- nulltoken

你无法从中推送的事实可能是任何协作使用的最大限制。 - Nevik Rehnel

确实如此。然而，文档指出，如果您只对具有悠久历史的大型项目的最近历史感兴趣，并且希望将修复作为补丁发送，则浅克隆可能很有趣。这适用于像Linux或Git这样不基于拉取请求的项目的不同类型的协作工作流程。 - nulltoken

0

如果有大量的文件版本，您的对象数据库随着时间的推移将变得越来越大。

默认情况下，Git使用zlib压缩算法存储单个blob。但是，可以告诉Git将多个对象合并为一个pack文件，该文件还使用增量压缩方法以节省空间。您的整个历史记录仍然存在，只是需要比执行基于先前状态的命令（例如，检出旧版本）需要更长时间来解包。但我需要强调这一点非常小。老实说，增加不到一秒的时间。

- xero

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- akonsu · Accepted Answer