Как удалить старые версии медиафайлов из репозитория git

У меня есть репозиторий Git с несколькими огромными медиа-файлами (изображениями и аудиофайлами). Несколько версий этих медиафайлов были последовательно переданы в репо. Файлы являются последовательно уточненными версиями одних и тех же активов и имеют одно и то же имя.

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

5 ответов


У меня есть скрипт (github gist здесь), чтобы удалить выбор нежелательных папок из всей истории репозитория git или удалить все, кроме последней версии папки.

трудно предположить, что все репозитории git находятся в ~/repos, но это легко изменить. Он также должен быть легко адаптирован для работы с отдельными файлами.


старая нить, но в случае, если кто-то еще спотыкается здесь...

GitHub & Bitbucket оба рекомендуют использовать BFG Repo-Cleaner.

посмотреть:
GitHub: Удалить Конфиденциальные Данные
Bitbucket: Уменьшить Размер Репозитория & Bitbucket: поддержка репозитория Git

пример для удаления файлов более 1 мегабайта, а также jpgs, pngs и mp3s, которые не находятся в Голова:

# First get the latest bfg.jar, then:
$ git clone --mirror git://example.com/some-big-repo.git
$ java -jar bfg.jar --strip-blobs-bigger-than 1M --delete-files '*.{jpg,png,mp3}' some-big-repo.git
$ cd some-big-repo.git
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
$ git push

Примечание: теперь вы нажали обновленные обороты, удаленный репозиторий также должен запустить его git gc ...иначе вы не увидите уменьшение размера. (см., например https://stackoverflow.com/a/28782154/3419541)

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


проверьте раздел "удаление объектов" в главе обслуживание и восстановление данных в книге ProGit. В нем содержатся шаги по удалению объектов из репозитория git. Но предупреждаю, что это разрушительно.


Как уже упоминалось, вы будете переписывать историю здесь, поэтому вам нужно будет заставить сотрудников (если они есть) сделать git rebase.

что касается удаления определенного файла из истории,Github имеет хорошее пошаговое руководство.

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

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

https://git-scm.com/docs/git-submodule

https://git-scm.com/book/en/v2/Git-Tools-Submodules


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

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