# 存储库限制

了解存储库限制。

某些类型的存储库资源可能非常大，因此需要在 GitHub 上进行大量处理。 因此，可设置限制，以确保申请在合理的时间内完成。 超过建议的最大限制会增加存储库健康状况下降的风险，包括但不限于基本 Git 操作响应时间缓慢和用户界面延迟。

> \[!NOTE] 尽管遵循这些准则可以提高存储库稳定性，但它不能保证可支持性，因为其他因素可能会导致意外行为。

以下大多数限制都会影响 GitHub 和 API。

## 存储库大小

为了确保获得最佳性能和可管理性，我们建议将存储库的结构和大小保持在以下最大限制范围内。

* 磁盘上大小：10 GB\*\*\*\*

  磁盘上大小是指 `.git` 文件夹（存储库的压缩形式）的大小。 大型存储库可能会减慢提取操作的速度，并增加开发人员和 CI 的克隆时间。 若要管理存储库大小，请执行以下操作：

  * 将 Git 大型文件存储 （Git LFS） 用于二进制文件。
  * 在 Git 外部（例如在对象存储中）存储通过编程生成的文件。

* 目录宽度（单个目录中的条目数）：3,000\*\*\*\*

  如果目录包含大量频繁修改的文件，则会显著增加存储库的维护成本并降低基本 Git 操作的性能。 通过将文件分段存放在浅目录结构中，可以减小这些树的大小，并减少创建的新数据。

* 目录深度：50\*\*\*\*

  深目录树会减慢历史记录浏览操作。

* 分支数：5,000\*\*\*\*

  大量分支可能会导致提取操作中出现不必要的数据，从而减慢传输，或者在极端情况下限制存储库性能。

## 活动

为了避免限速和性能问题，我们建议遵循以下操作限制性规定。

* **推送大小**：此限制强制为 2GB。

* 单个对象大小：\*\*\*\*

  建议的最大限制为 1MB。 此限制强制为 100MB。 若要跟踪 Git 存储库中的大型文件，建议使用 Git LFS。 请参阅“[关于 Git 大文件存储系统](/zh/enterprise-server@3.22/repositories/working-with-files/managing-large-files/about-git-large-file-storage)”。

* **Git 读取操作（例如提取、克隆）**：

  建议的最大限制是每个存储库每秒 15 个操作。 大量的读取操作可能会导致存储库的性能受到限制。 在某些情况下，自动化过程（例如 CI、计算机用户或第三方应用程序）可能会降低存储库的性能。 请考虑优化 CI 的克隆策略和/或使用存储库缓存服务器。 请注意，浅克隆比完整克隆对服务器的成本和负担更小，因此性能可能更好。

* 推送速率：建议的最大限制是每个存储库每分钟 6 次推送\*\*\*\*。

## 文本限制

GitHub 显示某些文件的格式化预览，例如 Markdown 和美人鱼图。
GitHub 如果文件较小（通常小于 2 MB），则始终尝试呈现这些预览，但更复杂的文件可能会超时，要么回退到纯文本，要么根本不显示。 这些文件始终以原始格式提供，通过 `HOSTNAME/user/repo/raw` 提供服务，例如 `https://HOSTNAME/user/repo/raw/octocat/Spoon-Knife/main/index.html`。 单击“原始”按钮可获取文件的原始 URL。

## 拉取请求限制

为了减少拉取请求活动较多的存储库中的延迟和性能问题，我们建议保持在以下限制范围内。

* **（针对同一分支）打开的拉取请求数**：1,000

  如果针对同一分支的打开的拉取请求过多，则可能会减慢可合并性检查的速度，或导致超时。 如果使用合并队列，请考虑禁用“要求此分支在合并之前保持最新”设置。 这会将可合并性检查的范围仅限于队列中的拉取请求。

* 拉取请求合并速率：每分钟 1 个合并拉取请求\*\*\*\*

  每次合并都会对所有打开的拉取请求触发可合并性检查，这可能会导致性能瓶颈，尤其是在繁忙的存储库中。 这也可能导致抢先合并的情况，这种情况会影响开发人员的工作效率。 若要减少负载，请在使用合并队列时禁用“要求此分支在合并之前保持最新”设置。

## 差异限制

因为差异可能很大，所以我们会对评论、拉取请求和比较视图的差异施加限制：

* 在拉取请求中，总差异不得超过\_可加载的 20,000 行\_或 *1 MB* 的原始差异数据 。
* 任何单个文件的差异都不得超过\_可加载的 20,000 行\_或 *500 KB* 的原始差异数据 。               为单个文件自动加载 \_400 行\_和 *20 KB*。
* 单一差异中的最大文件数限于 *300*。
* 单一差异中可呈现的文件（如图像、PDF 和 GeoJSON 文件）最大数量限于 *25*。

受限差异的某些部分可能会显示，但超过限制的任何部分都不会显示。

## 提交列表限制

比较视图和拉取请求页显示 `base` 和 `head` 修订之间的提交列表。 这些列表被限制为最多 250 个提交。 如果超过该限制，将会出现一条表示附加评论的注释（但不显示）。

“提交”选项卡上显示的最大提交数为 **10,000**。 使用其他工具（如 `git rev-list --count mybranch`）在需要时对大量提交进行计数和枚举。

## 变基限制

使用“变基并合并”选项合并拉取请求时，提交数量限制为 **100** 个。  如果拉取请求的提交数超过 100 个，则需要创建合并提交、压缩并合并，或将提交拆分为多个拉取请求。

## 组织和账户限制

组织和帐户的仓库数不可超过 100,000 个。 当帐户的仓库数量接近 50,000 个时，会显示一个横幅，提示即将逼近限制\*\*\*\*。 此外，管理员还会收到电子邮件通知，而且每多创建 5,000 个仓库，审核日志就会更新一次。 请参阅“[关于仓库](/zh/enterprise-server@3.22/repositories/creating-and-managing-repositories/about-repositories#about-repository-ownership)”。

## 集成和 GitHub Apps

构建 GitHub集成时，请将用户生成的数据存储在自己的 GitHub 帐户中，而不是将其集中到帐户中。 这可确保用户能够完全控制其工作，并帮助您避免超出代码库的限制。