Каковы пределы файлов в Git (число и размер)?

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

Ответы

Ответ 1

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

[...] 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 может быть медленным, когда файл сильно изменяется.

Ответ 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    .

Ответ 3

Если вы добавляете слишком большие файлы (в моем случае, в Cygwin, XP, 3 GB RAM), ожидайте этого.

fatal: Недостаточно памяти, malloc не удалось

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

Update 3/2/11: Пила похожа на Windows 7 x64 с Tortoise Git. Используемые тонны памяти, очень медленная реакция системы.

Ответ 4

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

В тестовом репо есть 4 миллиона транзакций, линейная история и около 1,3 миллиона файлы.

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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