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

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

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

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

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

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

git gc

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

Объяснение

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 {} \;'

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

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

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

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

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

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

Итак, есть много способов заставить git работать с большими файлами.

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

вы сказали git, что эти файлы бинарные?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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