Перебазировать всех на измененную историю git после ответвления фильтра

Question

В нашем репозитории git есть куча больших файлов в истории, которые больше не нужны. Я хочу удалить их, используя метод ответвления фильтра, описанный в Pro Git:

http://git -scm.com / книга / EN / v2 / GIT-Внутренность-техническое обслуживание и-Data-Recovery

Затем я буду использовать git push --force all для отправки этого в наш общий репозиторий, как описано здесь:

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

НО. Pro Git говорит, что мне нужно сделать ребаз, так как я меняю историю. Мы лишь редко использовали rebase, обычно просто как альтернативный способ слияния. Я могу сделать повторное клонирование всех, но это последнее средство; у нескольких разработчиков есть локальные ветки с изменениями, которые они хотели бы сохранить.

Итак: Что именно нужно будет сделать каждому в наших локальных репозиториях, чтобы перейти на недавно измененное общее репо? И нужно ли делать это один раз для каждой ветви отслеживания? Наше хранилище называется origin, а master ветка master, если вы хотите дать пошаговые инструкции (и я бы с удовольствием, если бы вы это сделали).

Answer 1

Ключ для каждого отдельного разработчика состоит в том, чтобы не потерять свою исходную ссылку на master до тех пор, пока они не выполнят свою перебазировку. Чтобы сделать это, попросите их выполнить fetch (, а не a pull) после принудительного нажатия, затем для каждой локальной ветви выполните:

git rebase --onto origin/master master <local_branch>

Когда это будет сделано, они смогут оформить заказ на master и обновить его:

git pull --force

Answer 2

Вот вариант.

• Создайте перебазированный мастер в ветке с именем rebased_master (вместо вашего исходного master).
• Вы бы затем подтолкнули эту ветвь, и все ваши разработчики сделали это и перенесли свои локальные ветки на rebased_master.Если они отбрасывают их из эквивалентного коммита до перебазирования и не имеют никаких изменений в файлах, которые вы удаляете, все должны быть в порядке.
• Как только каждый переместит свои ветки разработчика на rebased_master, вы можете удалить свои исходные master и move rebased_master на master

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