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

Question

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

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

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

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

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

Answer 1

Вы мусор собираете?

git gc

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

Answer 2

Объяснение

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

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

Решение

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

Вы сказали git, что эти файлы являются двоичными?

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

Answer 8

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

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

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

Answer 9

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

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

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

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

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

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

Кроме того, дайте парню время повзрослеть. Это все еще незрелое, но у этого есть много импульса. Со временем, я думаю, что практическая природа Линуса победит пуристов OSS, и git в конечном итоге будет использоваться в более широкой области.

Answer 10

Просто настройте файлы так, чтобы они игнорировались.См. Ссылку ниже:

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