Можно ли очистить файлы удаленного репо с плохими коммитами на GitHub?

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

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

Проблема: репо занимает слишком много времени, чтобы вытянуть / извлечь через Дженкинс, через плагин GitSCM. Время ожидания истекает через 10 минут. В этом репо хранятся тысячи коммитов и десятки тегов, поэтому я не могу произвольно установить определенный коммит в качестве хорошей точки для начала и усечения остальных.

Мои выводы: Попытка сделать то, что, по-видимому, делает плагин GitSCM, практически не вызывает проблем и не требует времени. Тем не менее, он по-прежнему невероятно медленный, просто не более 10 минут, поэтому нам, вероятно, следует это исправить, даже если плагин вызывает обостренные проблемы с производительностью.

Возможные оптимизации: я обнаружил, что несколько коммитов были добавлены в основном DLL. Эти библиотеки были удалены с помощью новых коммитов. Однако размер репо по-прежнему составляет сотни мегабайт по сравнению с тем, что фактически используется локальной файловой системой. Прямо сейчас, главная ветвь находится примерно в 4 МБ вне .git папка, которая составляет около 300 МБ.

Цель: избавиться от как можно большего количества этих 300 МБ, не раздражая людей, теряя историю / теги

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

Уменьшить размер репозитория git
Как удалить неиспользуемые объекты из репозитория git?
Почему git не уменьшит размер хранилища?

После того, как я попробовал решения этих вопросов, я только увеличил размер репо, а не уменьшил его, что, честно говоря, меня предупредили в ответах на один из этих вопросов.

Учитывая предысторию этой проблемы, детали проблемы и ранее упомянутые вопросы, можно ли выполнить то, что я пытаюсь сделать на репозитории с удаленным хостингом, и если да, что конкретно мне следует запустить или попросить наших администраторов GHE запустить если я лично не могу сделать обновление?

Это привело к росту:

git reflog expire --all --expire=now
git gc --prune=now --aggressive
git filter-branch --index-filter "git rm --cached --ignore-unmatch *.dll" --prune-empty -- --all
git push origin master

Однако после запуска первых двух команд размер папки.git уменьшился только на 40 МБ; это не соответствовало тому, на что я надеялся, поэтому я попробовал следующую команду в последовательности, которая при удаленном нажатии заставила репо расти, а не сокращаться. Количество объектов увеличилось с 45 до 60 тысяч.

Источник

2 ответа

Решение

Хитрость в том, что я не хочу связываться с историей, если это можно сделать,

Но вы сделаете следующее: ветвь фильтра git или (проще в использовании) очиститель репозитория BFG перезапишет историю (SHA1s) коммитов этого репо, заставив вас git push --force конечный результат возвращается к удаленному репо.
Это не имеет большого значения, учитывая, что репо является старым (т. Е. Больше не поддерживается активно), но все же должно быть принято во внимание.

Репо занимает слишком много времени, чтобы вытащить / извлечь через Дженкинс, через плагин GitSCM.

Дженкинс здесь вообще не должен участвовать: вы можете локально клонировать репо, почистить его и отодвинуть назад.
Плюс, тайм-аут в Дженкинсе может быть увеличен.

Это привело к росту:

Эти команды reflog / gc предполагается использовать после ответвления фильтра или BFG, а не до.

Источник

Я не собираюсь принимать свой собственный ответ. VonC выполнил замечательную задачу, пытаясь втиснуть ответ в комментарии, чтобы удовлетворить мои очень специфические требования, которые, возможно, не сдерживают других людей с подобными проблемами - кроме того, VonC упомянул использование BFG, что в итоге и разблокировало меня. Заставить работать только с git было бы неплохо, но так как BFG абсолютно бесплатен (а также намного быстрее, чем git filter-branch Я не могу игнорировать это как альтернативу решению проблем с git.

Чтобы разблокировать наши удаленные сборки, уменьшив размер репо в пределах .git папку, я использовал бесплатный инструмент BFG Repo Cleaner и точно следовал его инструкциям. Уменьшился размер .git папка с оригинального размера 300 МБ, до 80 МБ. Учитывая, что в репо было более 7 тыс. Коммитов, я не собираюсь жаловаться на .git папка еще большая. Эта операция определенно ускорила процесс возможности клонирования репо.

Как

Полное раскрытие: некоторые из этих шагов непосредственно скопированы из документации BFG Repo Cleaner, которая связана с шагом #2. Также предполагается, что вы используете Windows, поэтому обновляйте синтаксис оболочки по мере необходимости.

  1. Установите Java, если у вас его еще нет
  2. Возьмите бесплатный инструмент BFG Repo Cleaner со своего сайта, который также является страницей их документации.
  3. Если вы не хотите делать точно такую ​​же операцию, как я, где я удаляю все типы файлов .DLL, проверьте краткую документацию BFG, чтобы узнать о том, что еще доступно
  4. Откройте командную консоль и выполните мелкий клон, используя --mirror для вашего репо как такового:
    git clone --mirror https://github.com/some-big-repo.git
  5. Если java.exe не в вашем пути, либо временно добавьте этот каталог в PATH с Set PATH=%PATH%;C:\PathToJavaBin или вызовите его напрямую и убедитесь, что обновили эту команду с именем файла JAR, чтобы приведенная ниже команда соответствовала тому, что находится в вашей файловой системе, как таковое:
    C:\PathToJavaBin\java.exe -jar C:\PathToBFGJar\bfg.jar --delete-files *.dll some-big-repo.git
  6. бежать cd some-big-repo.git
  7. бежать git reflog expire --expire=now --all
  8. бежать git gc --prune=now --aggressive
  9. бежать git push

И это было все:)

Источник
Другие вопросы по тегам