Які обмеження файлів у Git (кількість та розмір)?

Хтось знає, які обмеження в Git мають кількість файлів та розмір файлів?

Це повідомлення від самого Лінуса може допомогти вам в деяких інших обмеженнях

[...] CVS, тобто він дійсно в основному орієнтується на модель "один файл за часом".

Що приємно тим, що ви можете мати мільйон файлів, а потім перевірити лише деякі з них - ви ніколи навіть не побачите вплив інших 999,995 файлів.

Git принципово ніколи насправді не виглядає менше, ніж цілий репо. Навіть якщо ви трохи обмежите речі (наприклад, перевірте лише частину, або історія повернеться трохи назад), git закінчується як і раніше завжди піклуючись про все, і несе знання навколо.

Тож git масштабує дуже погано, якщо ви змусите його дивитися на все як на одне величезне сховище. Я не думаю, що ця частина справді виправлена, хоча ми, можливо, можемо її покращити.

І так, тоді виникають проблеми "великого файлу". Я дійсно не знаю, що робити з величезними файлами. Ми їх смокчемо, я знаю.

Детальніше дивіться в іншій моїй відповіді : обмеження Git полягає в тому, що кожне сховище повинне представляти " когерентний набір файлів ", "всю систему" саме по собі (не можна тегувати "частиною сховища").
Якщо ваша система складається з автономних (але взаємозалежних) частин, ви повинні використовувати підмодулі .

Як показано у відповіді Талджо , обмеженням може бути системний один (велика кількість файлів), але якщо ви зрозумієте природу Git (про когерентність даних, представлену її ключами SHA-1), ви зрозумієте справжній "ліміт" це використання, тобто ви не повинні намагатися зберігати все у сховищі Git, якщо тільки ви не готові завжди отримувати або тегувати все назад. Для деяких великих проектів це не мало б сенсу.

Для більш глибокого перегляду меж git див. " Git з великими файлами "
(де згадується git-lfs : рішення для зберігання великих файлів поза git repo. GitHub, квітень 2015)

Три питання, які обмежують git repo:

• величезні файли ( xdelta для packfile є лише в пам'яті, що не добре для великих файлів)
• величезна кількість файлів , що означає, один файл на крапку, і повільний git gc для генерації одного пакету файлів за один раз.
• величезні пакети файлів, індекс packfile неефективний для отримання даних з (величезного) packfile.

Більш свіжа тема (лютий 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 займає деякий час. Робоче дерево досить велике, тому операції, які оглядають весь робочий каталог, займають досить багато часу. Однак ця репо використовується лише для зберігання даних, тому це лише купа автоматизованих інструментів, які обробляють її. Витягнення змін із РЕПО набагато, набагато швидше, ніж yсинхронізація одних і тих же даних.

%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 Kernel, і Android мають менше 900 МБ.

Рекомендоване рішення на цій сторінці - розділити ваш проект на менші шматки.

git має обмеження 4G (32 біт) для репо.

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