# Ограничения репозитория Сведения об ограничениях для репозиториев. Некоторые типы ресурсов репозиториев могут быть довольно большими, требуя чрезмерной обработки на GitHub. Для обеспечения выполнения запросов в разумные сроки установлены ограничения. Превышение рекомендуемого максимального предела повышает риск снижения работоспособности репозитория, который включает в себя, но не ограничивается временем отклика для базовых операций Git и задержки пользовательского интерфейса. > \[!NOTE] Следуя этим рекомендациям, он не гарантирует поддержку, так как другие факторы могут привести к непредвиденному поведению. Большинство приведённых ниже ограничений влияют и GitHub на API. ## Размер репозитория Чтобы обеспечить оптимальную производительность и управляемость, рекомендуется оставаться в пределах следующих максимальных ограничений для структуры и размера репозитория. * **Размер** диска: 10 ГБ Размер на диске относится к размеру `.git` папки (сжатой форме репозитория). Большие репозитории могут замедлить операции получения и увеличить время клонирования для разработчиков и CI. Управление размером репозитория: * Используйте Хранилище больших файлов Git (Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git)) для двоичных файлов. * Храните файлы, созданные программным способом за пределами Git, например в хранилище объектов. * **Ширина каталога (число записей в одном каталоге)**: 3000 Каталоги, содержащие многочисленные часто измененные файлы, могут значительно увеличить затраты на обслуживание репозитория и снизить производительность базовых операций Git. Сегментирование файлов в неглубокую структуру каталогов уменьшит размер этих деревьев и приведет к снижению размера новых данных. * **Глубина** каталога: 50 Глубокие деревья каталогов могут медленнее выполнять операции, выполняемые в журнале. * **Число ветвей**: 5000 Большое количество ветвей может привести к ненужным данным в операциях получения, что приводит к медленному времени передачи или в крайних случаях регулирование производительности репозитория. ## Действие (Activity) Чтобы избежать проблем с регулированием и производительностью, рекомендуется оставаться в пределах следующих операционных ограничений. * **Размер** отправки: это ограничение применяется в 2 ГБ. * **Размер** одного объекта: Рекомендуемое максимальное ограничение — 1 МБ. Это применяется в 100 МБ. Чтобы отслеживать большие файлы в репозитории Git, мы рекомендуем использовать Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git). См [. раздел AUTOTITLE](/ru/enterprise-server@3.22/repositories/working-with-files/managing-large-files/about-git-large-file-storage). * **Операции чтения Git (например, получение, клоны)**: Рекомендуемое максимальное ограничение — 15 операций в секунду в репозитории. Большие объемы операций чтения могут привести к регулированию производительности репозитория. Автоматизированные процессы, такие как CI, пользователи компьютеров или сторонние приложения, могут снизить производительность репозитория в некоторых случаях. Рекомендуется оптимизировать стратегию клонирования CI и (или) использовать сервер кэш репозитория. Обратите внимание, что неглубокие клоны будут накладывать меньшие затраты и нагрузку на сервере, чем полные клоны и, следовательно, могут работать лучше. * **Скорость** отправки: рекомендуемое максимальное ограничение составляет 6 push-уведомлений в минуту в репозитории. ## Ограничения на текст GitHub отображает форматированные предварительные просмотры некоторых файлов, таких как диаграммы Markdown и Mermaid. GitHub Всегда пытаются отрендерить эти предпросмотры, если файлы небольшие (обычно меньше 2 МБ), но более сложные файлы могут выходить из времени и либо возвращаться к обычному тексту, либо вообще не отображаться. Эти файлы всегда доступны в необработанных форматах, которые обслуживаются через `HOSTNAME/user/repo/raw`, например `https://HOSTNAME/user/repo/raw/octocat/Spoon-Knife/main/index.html`. Чтобы получить необработанный URL-адрес файла, нажмите кнопку **Необработанный**. ## Ограничения запросов на вытягивание Чтобы уменьшить задержки и производительность в репозиториях с высоким действием запроса на вытягивание, рекомендуется оставаться в пределах следующих ограничений. * **Открытые запросы на вытягивание (в той же ветви):** 1000 Наличие множества открытых запросов на вытягивание, предназначенных для одной ветви, может замедлить проверку совместимости слиянием или привести к истечении времени ожидания. Если вы используете очередь слияния, попробуйте отключить параметр "требовать, чтобы эта ветвь была обновлена перед слиянием". Это ограничивает проверку совместимости слиянием только для запросов на вытягивание в очереди. * **Скорость** слияния запросов на вытягивание: 1 объединенный запрос на вытягивание в минуту Каждое слияние запускает проверки совместимости для всех открытых запросов на вытягивание, что может привести к узким местам производительности, особенно в занятых репозиториях. Это также может привести к ситуации, которая влияет на производительность разработчиков. Чтобы уменьшить нагрузку, отключите параметр "Требовать актуальность этой ветви перед слиянием" при использовании очереди слияния. ## Ограничения на различия Так как различия могут стать очень большими, на различия в фиксациях, запросах на вытягивание и представлениях сравнения налагаются указанные ниже ограничения. * В запросе на вытягивание общий объем необработанных данных различий не может превышать *20 000 загружаемых строк* или *1 МБ*. * Объем необработанных данных различий в одном файле не может превышать *20 000 загружаемых строк* или *500 КБ*. Для одного файла автоматически загружаются *четыреста строк* или *20 КБ*. * Максимальное количество файлов в одном различии ограничено *300*. * Максимальное число отрисовываемых файлов (например, изображений, PDF-файлов и файлов GeoJSON) в одном различии ограничено *25*. Некоторые части ограниченного различия могут отображаться, но всё свыше ограничения не отображается. ## Ограничения на списки фиксаций На страницах представлений сравнения и запросов на вытягивание отображается список фиксаций между версиями `base` и `head`. Эти списки ограничены **250** фиксациями. Если это ограничение превышено, в примечании сообщается о наличии дополнительных фиксаций (но они не отображаются). Максимальное количество фиксаций, отображаемых на вкладке "Фиксации", составляет **10 000**. При необходимости используйте другие средства, такие как `git rev-list --count mybranch` подсчет и перечисление большого объема фиксаций. ## Ограничения повторной базы Объединение запроса на вытягивание с помощью параметра "Перебаза и слияние" ограничено **100** фиксациями. Если у вас есть запрос на вытягивание с более чем 100 фиксациями, необходимо создать фиксацию слияния, сквашировать и объединить или разделить фиксации на несколько запросов на вытягивание. ## Ограничения организации и учетной записи Организации и учетные записи не могут превышать **100 000** репозиториев. Если учетная запись превышает **50 000** репозиториев, появится баннер, отметив приближающийся предел. Кроме того, администраторы получат Уведомления по электронной почте, а журнал аудита обновляет все дополнительные 5000 репозиториев. См [. раздел AUTOTITLE](/ru/enterprise-server@3.22/repositories/creating-and-managing-repositories/about-repositories#about-repository-ownership). ## Интеграции и GitHub Apps При построении интеграции GitHubна , храните пользовательские данные в их собственных GitHub аккаунтах, а не централизуйте их в вашем аккаунте. Это гарантирует, что пользователи сохраняют полный контроль над своей работой и помогают избежать превышения ограничений репозитория.