git очень медленный при отслеживании больших двоичных файлов

Question

Мой проект составляет шесть месяцев, а git очень медленный. Мы отслеживаем около 30 файлов размером от 5 МБ до 50 МБ. Это двоичные файлы, и мы храним их в git. Я считаю, что эти файлы делают git медленными.

Есть ли способ убить все файлы размером> 5 МБ из репозитория. Я знаю, что потеряю все эти файлы, и все в порядке со мной.

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

Следует отметить, что git работает не только на моей машине, но и развертывание приложения в промежуточной среде теперь занимает около 3 часов.

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

Answer 1

Просто установите файлы для игнорирования. Смотрите ссылку ниже:

http://help.github.com/git-ignore/

Answer 2

вы сказали мерзавца эти файлы являются бинарными?

например. добавлено *.ext binary в ваш репозиторий. .gitattributes

Answer 3

Собирать ли мусор?

git gc 

Это делает существенную разницу в скорости даже для небольших репозиториев.

Answer 4

Объяснение

Git действительно хорош в огромных историй небольших текстовых файлов, так как он может хранить их и их изменения эффективно. В то же время git очень плохо работает в двоичных файлах и наивно хранит отдельные копии файла (by default, at least). Репозиторий становится огромным, а затем он замедляется, как вы уже заметили.

Это распространенная проблема среди DVCS, усугубляемая тем, что каждый раз, когда вы клонируете, вы загружаете каждую версию каждого файла («весь репозиторий»). Ребята в Kiln работают над плагином, чтобы обрабатывать эти большие файлы, похожие на Subversion, который загружает только исторические версии по запросу.

Решение

Эта команда выводит список всех файлов в текущем каталоге размером> = 5 МБ.

find . -size +5000000c 2>/dev/null -exec ls -l {} \; 

Если вы хотите удалить файлы из всей истории репозитория, вы можете использовать эту идею с git filter-branch ходить историю и избавиться от всех следов больших файлов. После этого все новые клоны репозитория будут более компактными. Если вы хотите приспособить репозиторий без клонирования, вы найдете указания на man page (см. «Контрольный список для сокращения репозитория»).

git filter-branch --index-filter \ 
    'find . -size +5000000c 2>/dev/null -exec git rm --cached --ignore-unmatch {} \;' 

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

Answer 5

Это потому, что git не масштабируется.

Это серьезное ограничение в git, которое было заглушено защитой git. Найдите списки рассылки git, и вы обнаружите, что сотни пользователей задаются вопросом, почему просто скудные 100 МБ изображений (скажем, для веб-сайта или приложения) приносят git на колени. Проблема заключается в том, что почти все git полагаются на оптимизацию, которую они называют «упаковкой». К сожалению, упаковка неэффективна для всех, кроме самых маленьких текстовых файлов (то есть исходного кода). Хуже того, он растет все меньше и меньше, поскольку история возрастает.

Это действительно смущающий недостаток в git, который рекламируется как «быстрый» (несмотря на отсутствие доказательств), и разработчики git хорошо знают об этом. Почему они не исправили это? Вы найдете ответы на список рассылки git от разработчиков git, которые не узнают проблему, потому что документы Photoshop (* .psd) являются проприетарным форматом. Да, это действительно так плохо.

Вот результат:

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

Не используйте git, если у вас есть большая база кода, двоичные файлы, огромная история и т. Д. Только одно из наших РЕПО - это ТБ. Гит не справляется с этим. VSS, CVS и SVN отлично справляются с этим. (SVN раздувается вверх.)

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

Answer 6

Вот цензура пересмотр предназначен, чтобы быть менее отрицательными и воспалительными:

Git имеет хорошо известную слабость, когда речь идет о файлах, которые не выравнивает построчно текстовые файлы. В настоящее время нет решения, и никакие планы, объявленные основной командой git для решения этой проблемы. Возможны временные решения, если ваш проект небольшой, скажем, 100 МБ или около того. Существуют ветви проекта git для решения этой проблемы масштабируемости, но в настоящее время эти ветви не являются зрелыми. Некоторые другие системы контроля версий не имеют этой конкретной проблемы. Вы должны рассматривать эту проблему как один из многих факторов при принятии решения о выборе git в качестве вашей системы контроля версий.

Answer 7

Я работаю с Git с 2008 года как на окнах, так и на GNU/linux, и я большую часть файлов, которые я отслеживаю, это двоичные файлы. Некоторые из моих репозиториев - несколько GB и содержат Jpeg и другие медиа. У меня много компьютеров как дома, так и на работе, работающей с Git.

У меня никогда не было симптомов, описанных в исходном посте. Но всего пару недель назад я установил MsysGit на старый ноутбук Win-XP и почти все, что я сделал, он остановил git. Даже тест с двумя или тремя небольшими текстовыми файлами был смехотворно медленным. Мы говорим о 10 минутах, чтобы добавить файл меньше, чем 1k ... похоже, что git-процессы оставались живыми навсегда. Все остальное работало, как ожидалось, на этом компьютере.
Я отказался от последней версии до версии 1.6, и проблемы были упущены ...
У меня есть другие ноутбуки того же бренда, также с Win-XP, установленным одним и тем же отделом ИТ, с тем же изображением, где Git отлично работает независимо от версии ... Так что с этим конкретным компьютером должно быть что-то странное.

Я также провел несколько тестов с бинарными файлами и сжатием. Если у вас есть BMP-изображение, и вы вносите небольшие изменения в него и совершаете их, git gc сжимается очень хорошо. Итак, я пришел к выводу, что сжатие не зависит от того, являются ли файлы двоичными или нет.

Answer 8

Нет ничего особенного в бинарных файлах и способах, которыми git обрабатывает их. Когда вы добавляете файл в репозиторий git, заголовок добавляется и файл сжимается zlib и переименовывается после хэша SHA1. Это точно так же, независимо от типа файла. В zlib-сжатии нет ничего плохого в двоичных файлах.

Но в некоторых точках (нажатие, gc) Git начинает смотреть на возможность дельта-сжатия содержимого. Если git находит файлы, похожие (имя файла и т. Д.), Он помещает их в ОЗУ и начинает сжимать их вместе. Если у вас есть 100 файлов, и каждый из них скажет 50 Мб, он попытается поместить 5 ГБ в память одновременно. Для этого вам нужно добавить еще кое-что, чтобы все работало. У вашего компьютера может не быть такого объема оперативной памяти, и он начинает меняться. Процесс требует времени.

Вы можете ограничить глубину дельта-сжатия, чтобы процесс не использовал столько памяти, но результат был менее эффективным. (core.bigFileThreshold, delta attribute, pack.window, pack.depth, pack.windowMemory и т. д.)

Итак, есть много идей, которые вы можете сделать, чтобы git отлично работал с большими файлами.

Answer 9

Одним из способов ускорения действий является использование флага --depth 1. См. Справочную страницу. Я не великий гут-гуру, но я считаю, что это говорит о эквиваленте p4 get или svn get, то есть он дает вам только последние файлы, а не «дайте мне все изменения всех файлов за все время», что и есть git clone.

Answer 10

Вы также можете рассматривать BFG Repo Cleaner как более простой способ очистки больших файлов.

https://rtyley.github.io/bfg-repo-cleaner/