关于 GitHub 上的大文件

关于 GitHub Enterprise Cloud 的大小限制

GitHub Enterprise Cloud 尝试为所有 Git 存储库提供丰富的存储空间，但存在文件和存储库。 为确保用户的性能和可靠性，我们积极监控整个存储库运行状况的信号。 存储库运行状况是各种交互因素共同作用的结果，包括大小、提交频率、内容和结构。

文件大小限制

GitHub Enterprise Cloud 限制存储库中允许的文件大小。 如果尝试添加或更新大于 50 MiB 的文件，您将从 Git 收到警告。 更改仍将成功推送到仓库，但您可以考虑删除提交，以尽量减少对性能的影响。 有关详细信息，请参阅从存储库的历史记录中移除文件。

GitHub Enterprise Cloud 阻止大小超过 100 MiB 的文件。

要跟踪超出此限制的文件，必须使用 Git Large File Storage (Git LFS)。 有关详细信息，请参阅“关于 Git Large File Storage”。

如果需要在存储库中分发大文件，则可以在 GitHub.com 上创建版本，而不是跟踪文件。 有关详细信息，请参阅分发大型二进制文件。

Git 不是为处理大型 SQL 文件而设计的。 要与其他开发人员共享大型数据库，建议使用文件共享服务。

存储库大小限制

建议仓库保持较小，理想情况下小于 1 GB，强烈建议小于 5 GB。 较小的仓库克隆速度更快，使用和维护更容易。 如果您的仓库过度影响我们的基础架构，您可能会收到来自 GitHub 支持 的电子邮件，要求您采取纠正措施。 我们力求灵活，特别是对于拥有很多协作者的大型项目，并且尽可能与您一起找到解决方案。 您可以有效地管理仓库的大小和整体运行状况，以免您的仓库影响我们的基础架构。 可以在 github/git-sizer 存储库中找到用于存储库分析的建议和工具。

外部依赖项可能导致 Git 仓库变得非常大。 为避免外部依赖项填满仓库，建议您使用包管理器。 常见语言的常用包管理器包括 Bundler、Node 的包管理器和 Maven。 这些包管理器支持直接使用 Git 仓库，因此不需要预打包的来源。

Git 未设计为用作备份工具。 但是，有许多专门为执行备份而设计的解决方案，例如 Arq、Carbonite 和 CrashPlan。

从仓库的历史记录中删除文件

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

如果文件使用最近的提交添加，而你尚未推送到 GitHub.com，可以删除文件并修改提交：

1. 打开终端终端Git Bash。

2. 将当前工作目录更改为您的本地仓库。

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

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

4. 使用 --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
   

5. 将提交推送到 GitHub.com：

   $ git push
   # Push our rewritten, smaller commit
   

删除之前提交中添加的文件

如果在之前的提交中添加了文件，则需要将其从仓库历史记录中删除。 要从仓库的历史记录中删除文件，建议使用 git filter-repo 命令。 有关详细信息，请参阅“从存储库中删除敏感数据”。

或者，如果不想安装其他工具，可以使用交互式变基删除有问题的提交。 要执行此操作：

• 必须知道是哪些提交添加或修改了相关文件。
• 这些提交必须只属于一个分支。
• 这些提交所在的这个分支自应用提交以来不得进行任何合并。

有关交互式变基的详细信息，请参阅“在命令行中使用 Git rebase”。 如果不确定是否满足使用交互式变基进行修复的必要条件，则应使用 git filter-repo。

分发大型二进制文件

如果需要在存储库内分发大型文件，可以在 GitHub.com 上创建发行版。 发行版允许您打包软件、发行说明和指向二进制文件的链接，以供其他人使用。 有关详细信息，请访问“关于发行版”。

我们不限制二进制发行版文件的总大小，也不限制用于传递它们的带宽。 但每个文件必须小于 2 GiB。