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