Обновите команду разработчиков с переписанной историей репозитория Git, удалив большие файлы

Question

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

После поиска в Интернете я пришел к выводу, что мой лучший (только?) Вариант - использовать git-filter-branch:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip' HEAD

Похоже, это хороший подход?

Предполагая, что ответ - да, у меня есть еще одна проблема, с которой приходится бороться. В руководстве git есть это предупреждение :

ВНИМАНИЕ! Переписанная история будет иметь разные имена объектов для всех объектов и не будет сходиться с исходной ветвью. Вы не сможете легко перемещать и распространять переписанную ветку поверх оригинальной ветви. Пожалуйста, не используйте эту команду, если вы не знаете всех последствий, и избегайте ее использования в любом случае, если для решения вашей проблемы будет достаточно простого коммита. (Обратитесь к разделу «ВОССТАНОВЛЕНИЕ ИЗ РЕБАЗЫ UPSTREAM» в git-rebase (1) для получения дополнительной информации о перезаписи опубликованной истории.)

У нас есть удаленное репо на нашем сервере. Каждый разработчик подталкивает и вытягивает из него. Исходя из приведенного выше предупреждения (и моего понимания того, как работает git-filter-branch), я не думаю, что смогу запустить git-filter-branch на своей локальной копии и затем нажать изменения.

Итак, я предварительно планирую выполнить следующие шаги:

1. Скажите всем моим разработчикам на некоторое время зафиксировать, нажать и перестать работать.
2. Войдите на сервер и запустите фильтр на центральном репо.
3. Попросите всех удалить свои старые копии и снова клонировать с сервера.

Это звучит правильно? Это лучшее решение?

Answer 1

Да, ваше решение будет работать. У вас также есть другой вариант: вместо того, чтобы делать это в центральном репо, запустите фильтр на вашем клоне и затем нажмите его обратно с git push --force --all. Это заставит сервер принимать новые ветки из вашего хранилища. Это заменяет только шаг 2; остальные шаги будут такими же.

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

Answer 2

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

Загрузка Java jar (требуется Java 6или выше) и выполните эту команду:

$ java -jar bfg.jar  --strip-blobs-bigger-than 1MB  my-repo.git

Любой BLOB-объект размером более 1 МБ (которого нет в вашем последнем коммите) будет полностью удален изистория вашего хранилища.Затем вы можете использовать git gc для удаления мертвых данных:

$ git gc --prune=now --aggressive

BFG обычно в 10-50 раз быстрее, чем выполнение git-filter-branch, и параметры настраиваются вокруг этих двух распространенных вариантов использования:

• Удаление Сумасшедшие большие файлы
• Удаление Пароли, учетные данные и другие Личные данные

Answer 3

Если вы не заставите своих разработчиков повторно клонировать, вероятно, им удастся перетащить большие файлы обратно. Например, если они аккуратно склеятся с новой историей, которую вы создадите, а затем произойдет с git merge из В локальной ветке проекта, которая не была перебазирована, родительский коммит слияния будет включать ветку проекта, которая в конечном итоге указывает на всю историю, которую вы стерли с помощью git filter-branch.

Answer 4

Ваше решение не завершено. Вы должны включить --tag-name-filter cat в качестве аргумента, чтобы фильтровать ветку, чтобы теги, которые содержат большие файлы, также были изменены. Вам также следует изменить все ссылки, а не только HEAD, так как фиксация может быть в нескольких ветвях.

Вот лучший код:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip' --tag-name-filter cat -- --all

У Github есть хороший гид: https://help.github.com/articles/remove-sensitive-data