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

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

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

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

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

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

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

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

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

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

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

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

• огромные файлы ( xdelta для packfile находится только в памяти, что плохо для больших файлов)
• огромное количество файлов , что означает, один файл на блоб, и медленный 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 может быть медленным, когда файл сильно изменяется.

Нет никаких реальных ограничений - все именуется 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    .

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

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

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

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

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

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

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

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

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

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

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

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

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

Я обнаружил, что это пытается сохранить огромное количество файлов (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 МБ.

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

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

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