Ответ 1

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

git gc

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

Ответ 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 {} \;'

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

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

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

Здесь результат:

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

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

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