Прямо сейчас я пытаюсь уменьшить раздутый репо, удаляя объекты git, связанные с давно удаленными двоичными файлами, в системе контроля версий. Я использую очиститель репозитория BFG, который успешно сокращает репо и оставляет текущий коммит без изменений, но я борюсь с тем, как организовать миграцию в уменьшенное репо.
Для контекста, все разработчикиотработать форки основного репо, и только объединять изменения через PR. Что касается миграции, я думаю, чтобы все извлекли последние изменения из апстрима, затем запустили задание BFG, принудительно подтолкнули, а затем заставили всех пересмотреть и повторно клонировать.
Это довольно просто,но все сложно, потому что у каждого есть история в своих собственных форках репо, чья история вот-вот будет коренным образом переписана. Я борюсь с тем, как позволить разработчикам переносить ветки объектов со своих старых вилок и клонов на свои новые вилки и клоны. Все, что я пробовал (т.е. добавляю старый репо в качестве удаленного и извлекающего), приносит намного больше истории, чем я хочу, или вообще никакой истории (например, cherry-pick);в идеале мы приносим столько истории, сколько было изменено в ветвях и их коммитах.
Есть ли здесь лучшая практика?