Каковы ограничения файла в Git (количество и размер)?

Question

Кто-нибудь знает, каковы ограничения Git для количества файлов и размера файлов?

Answer 1

Это сообщение от Сам Линус может помочь вам с некоторыми другими ограничениями

[...] CVS, то есть он действительно в значительной степени ориентирован на "один файл" за один раз "модель.

Что приятно, у вас может быть миллион файлов, а затем только проверка некоторые из них - вы никогда даже не увидите влияние других 999,995 файлов.

Гит принципиально никогда не смотрится меньше, чем весь репо. Даже если ты немного ограничить вещи (например, проверить только часть, или история идет немного назад), git заканчивает тем, что всегда заботится обо всем, и нести знания вокруг.

Так что мерзавец действительно плохо масштабируется, если заставить его смотреть на все как на единое целое огромный репозиторий. Я не думаю, что эта часть действительно исправима, хотя мы может улучшить его.

И да, тогда есть проблемы с "большими файлами". Я действительно не знаю что делать с огромными файлами. Мы сосем их, я знаю.

Подробнее см. В моем другом ответе : ограничение для Git состоит в том, что каждый репозиторий должен представлять собой " связный набор файлов ", сам по себе "вся система" ( не тег "часть репозитория").
Если ваша система состоит из автономных (но взаимозависимых) частей, вы должны использовать подмодулей .

Как показано ответом Talljoe , пределом может быть system one (большое количество файлов), но если вы действительно понимаете природу Git (о согласованности данных, представленной его ключи SHA-1), вы поймете, что истинный «предел» - это использование один: то есть вы не должны пытаться хранить все в репозитории Git, если вы не готовы чтобы всегда получить или пометить все обратно. Для некоторых крупных проектов это не имеет смысла.

---

Для более детального изучения ограничений git см. « git с большими файлами »
(в котором упоминается git-lfs : решение для хранения больших файлов вне git-репозитория. GitHub, апрель 2015 г.)

Три проблемы, ограничивающие git-репо:

• огромные файлы ( xdelta для packfile находится только в памяти, что плохо для больших файлов)
• огромное количество файлов , что означает, что один файл на BLOB-объект и медленный git gc генерируют по одному пакетному файлу за раз.
• огромные файлы пакета , с индексом файла пакета, неэффективным для извлечения данных из (огромного) файла пакета.

---

Более поздняя ветка (февраль 2015 г.) иллюстрирует ограничивающие факторы для репозитория Git :

Будет ли несколько одновременных клонов с центрального сервера также замедлять другие параллельные операции для других пользователей?

При клонировании сервер не блокируется, поэтому теоретически клонирование не влияет на другие операции. Хотя для клонирования может потребоваться много памяти (и много процессора, если вы не включите растровую функцию достижимости, что вам и нужно).

Будет ли git pull медленным?

Если мы исключим серверную сторону, размер вашего дерева является основным фактором , но ваши 25k-файлы должны быть хорошими (linux имеет 48k-файлы).

git push

На это не влияет то, насколько глубока история вашего репо или насколько широко ваше дерево, поэтому должно быть быстрым ..

Ах, количество ссылок может повлиять как на git-push, так и git-pull.
Я думаю, что Стефан знает лучше, чем я в этой области.

git commit '? (Это указано как медленное в ссылка 3 .) 'git status'? (Снова медленно в ссылке 3, хотя я этого не вижу.)
(также git-add)

Опять размер вашего дерева. При размере вашего репо, я не думаю, что вам нужно беспокоиться об этом.

Некоторые операции могут показаться не повседневными, но если веб-интерфейс часто вызывает их из GitLab / Stash / GitHub и т. Д., То они могут стать узкими местами. (например, 'git branch --contains', кажется, очень сильно пострадал от большого количества ветвей.)

git-blame может быть медленным, когда файл сильно изменяется.

Answer 2

Нет реального ограничения - все именуется 160-битным именем. Размер файла должен быть представлен в 64-битном числе, поэтому здесь нет никаких ограничений.

Однако есть практический предел. У меня есть репозиторий ~ 8 ГБ с> 880 000, и Git GC занимает некоторое время. Рабочее дерево довольно большое, поэтому операции, которые затем проверяют весь рабочий каталог, занимают довольно много времени. Этот репо используется только для хранения данных, так что это всего лишь набор автоматизированных инструментов, которые обрабатывают его. Извлечение изменений из репозитория намного, намного быстрее, чем повторная синхронизация тех же данных.

%find . -type f | wc -l
791887
%time git add .
git add .  6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status  0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G     .
%cd .git
%du -sh .
7.9G    .

Answer 3

Если вы добавляете файлы слишком большого размера (в моем случае ГБ, Cygwin, XP, 3 ГБ ОЗУ), ожидайте этого.

неустранимый: недостаточно памяти, malloc не удалось

Подробнее здесь

Обновление 3/2/11: видел аналогичные в Windows 7 x64 с Tortoise Git. Используется тонны памяти, очень и очень медленный отклик системы.

Answer 4

В феврале 2012 года в списке рассылки Git была очень интересная тема от Джошуа Редстоуна, инженера-программиста Facebook, тестирующего Git в огромном тестовом хранилище:

Тестовое репо имеет 4 миллиона коммитов, линейную историю и около 1,3 миллиона файлы.

Проведенные тесты показывают, что для такого репо Git непригоден (холодная операция длится минуты), но это может измениться в будущем. В основном производительность ограничивается количеством stat() обращений к модулю FS ядра, поэтому она будет зависеть от количества файлов в репо и эффективности кэширования FS. См. Также этот Гист для дальнейшего обсуждения.

Answer 5

Это зависит от вашего значения. Существуют практические ограничения по размеру (если у вас много больших файлов, это может быть очень медленно) Если у вас много файлов, сканирование также может выполняться медленно.

Впрочем, для модели нет особых ограничений. Вы, конечно, можете использовать это плохо и быть несчастным.

Answer 6

Я обнаружил, что это пытается сохранить огромное количество файлов (350k +) в репо. Да, магазин. Смеётся.

$ time git add . 
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total

Следующие выдержки из документации Bitbucket весьма интересны.

Когда вы работаете с клонированием и переносом репозитория DVCS, вы работаете со всем хранилищем и всей его историей. На практике, когда размер вашего хранилища превышает 500 МБ, вы можете начать сталкиваться с проблемами.

... 94% клиентов Bitbucket имеют репозитории объемом менее 500 МБ. Ядро Linux и Android имеют размер менее 900 МБ.

Рекомендуемое решение на этой странице - разделить ваш проект на более мелкие куски.

Answer 7

У меня есть большое количество данных, которые хранятся в моем репо как отдельные фрагменты JSON В нескольких каталогах содержится около 75 000 файлов, и это не сильно сказывается на производительности.

Проверка их в первый раз была, очевидно, немного медленной.

Answer 8

Я думаю, что было бы хорошо попытаться избежать фиксации больших файлов как части репозитория (например, дамп базы данных мог бы быть лучше в другом месте), но если учесть размер ядра в его репозитории, вы можете ожидать удобно работать с чем-то меньшим по размеру и менее сложным, чем это.

Answer 9

По состоянию на 2018-04-20 В Git для Windows есть ошибка , которая эффективно ограничивает размер файла до 4 ГБ макс при использовании этой конкретной реализации (эта ошибка распространяется и на lfs ) .

Answer 10

git имеет лимит 4G (32 бита) для репо.

http://code.google.com/p/support/wiki/GitFAQ