关于 GitHub 上的大文件

关于 GitHub 的大小限制

GitHub 力求为所有 Git 仓库提供充足的存储空间，尽管对文件和仓库大小设有硬性限制。为确保用户体验的性能和可靠性，我们会主动监控整体仓库健康状态的信号。仓库健康度取决于多个相互作用的因素，包括大小、提交频率、内容以及结构。

文件大小限制

GitHub 限制仓库中允许的文件大小。如果您尝试添加或更新大于 50 MiB 的文件，Git 会给出警告。更改仍会成功推送到您的仓库，但您可以考虑删除该提交以最小化性能影响。欲了解更多信息，请参见从仓库历史中删除文件。

注意

如果您通过浏览器向仓库添加文件，文件大小不能超过 25 MiB。更多信息请参见向仓库添加文件。

GitHub 阻止大于 100 MiB 的文件。

要跟踪超出此限制的文件，必须使用 Git 大文件存储（Git LFS）。更多信息请参见关于 Git 大文件存储。

如果您需要在仓库中分发大型文件，可以在 GitHub.com 上创建发布（Release），而不是直接跟踪这些文件。更多信息请参见分发大型二进制文件。

Git 并非为处理大型 SQL 文件而设计。若要与其他开发者共享大型数据库，我们建议使用文件共享服务。

我们建议仓库保持较小，理想情况下小于 1 GB，强烈建议不超过 5 GB。较小的仓库克隆速度更快，使用和维护也更便捷。如果您的仓库对我们的基础设施造成过大负担，可能会收到来自 GitHub 支持的电子邮件，要求您采取纠正措施。我们在灵活性方面会有所考虑，尤其是对拥有众多协作者的大型项目，并将在可能的情况下与您共同寻找解决方案。通过有效管理仓库的大小和整体健康度，您可以防止仓库影响我们的基础设施。您可以在 github/git-sizer 仓库中找到有关仓库分析的建议和工具。

外部依赖会导致 Git 仓库体积变得非常庞大。为了避免在仓库中堆积外部依赖，我们建议您使用包管理器。常见语言的流行包管理器包括 Bundler、Node 包管理器（npm）与 Maven。这些包管理器支持直接使用 Git 仓库，因此无需预打包的源码。

Git 并非设计为备份工具。不过，有许多专门用于执行备份的解决方案，例如 Arq、Carbonite 与 CrashPlan。

从仓库历史中删除文件

警告

这些操作会永久删除您本地计算机和 GitHub.com 上仓库中的文件。如果该文件很重要，请在仓库之外的目录中做好本地备份。

删除最近一次未推送提交中添加的文件

如果文件是随您最近一次提交添加的且尚未推送到 GitHub.com，您可以删除该文件并修改提交。

打开终端终端Git Bash。
将当前工作目录切换到本地仓库。

要删除文件，请输入 git rm --cached

$ git rm --cached GIANT_FILE
# Stage our giant file for removal, but leave it on disk

使用 --amend -CHEAD 提交此更改

$ git commit --amend -CHEAD
# Amend the previous commit with your change
# Simply making a new commit won't work, as you need
# to remove the file from the unpushed history as well

将您的提交推送到 GitHub.com

$ git push
# Push our rewritten, smaller commit

删除早期提交中添加的文件

如果您在早期的提交中添加了文件，需要将其从仓库历史中移除。我们推荐使用 git filter-repo 命令来删除仓库历史中的文件。更多信息请参见从仓库中删除敏感数据。

另外，如果您不想安装额外的工具，也可以使用交互式 rebase 来移除有问题的提交。操作步骤如下：

必须确定是哪一次（哪些）提交添加或修改了相关文件。

这些提交必须只位于单一分支上。

该分支自这些提交被应用后不得出现任何合并。

有关交互式 rebase 的更多信息，请参见在命令行使用 Git rebase。如果您不确定是否满足使用交互式 rebase 的条件，建议改用 git filter-repo。

分发大型二进制文件

如果您需要在仓库中分发大型文件，可以在 GitHub.com 上创建发布（Release）。发布让您能够打包软件、发布说明以及二进制文件的链接，供他人使用。更多信息请访问关于发布。

我们不对发布中二进制文件的总大小或传输带宽设限。但每个单独文件必须小于您计划中 Git LFS 的最大文件大小限制。参见关于 Git 大文件存储。

平台导航

本文内容