BFG Repo Cleaner — альтернатива свежему клону

Предисловие

Прежде чем мы углубимся в это, позвольте мне пояснить рекомендуемый процесс очистки истории Git в контексте активной команды разработчиков (независимо от того, какая технология используется для очистки — BFG Repo-Cleaner или git filter-branch):

1. Попрактикуйтесь в выполнении очистки несколько раз на локальной одноразовой копии вашего репозитория, чтобы вы были уверены, что сможете это сделать и получите желаемый результат, и знаете, сколько времени это займет.
2. COMMUNICATE WITH YOUR TEAM. This is essential, unavoidable (because Git is specifically built to complain and get in the way if history is rewritten) and just good practice for any team :-) You need to tell them:
   • Why the clean is happening (eg smaller repo!)
   • Когда планируется уборка, заранее предупредите их об этом.
   • Чтобы отправить всю свою работу в основной репозиторий до начала очистки — ее не нужно объединять с основной веткой, но вся работа должна быть включена. толкнул вверх на той или иной ветке.
   • Сообщите им, что им нужно будет удалить свои старые копии репозитория, когда очистка будет завершена, и повторно клонировать только что очищенный репозиторий.
3. Когда вся работа будет перенесена в основной репозиторий, выполните зеркальный клон основного репозитория. . СДЕЛАЙТЕ БЭКАП ЭТОГО КЛОНА, чтобы всегда можно было вернуться, если что-то пойдет не так.
4. Запустите очистку (с помощью BFG Repo-Cleaner или более медленного инструмента, такого как git filter-branch), и используйте git gc для обрезки мертвых объектов.
5. Как только вы убедитесь, что очистка прошла успешно, отправьте очищенную историю обратно в основное хранилище (поскольку это был клон mirror, все старые ветки/теги будут перезаписаны новой очищенной историей)
6. Сообщите своей команде, что пришло время удалить их старые копии репозитория и повторно клонировать очищенный репозиторий.

Итак, на ваши вопросы:

Что делать, если пользователь со старым репозиторием извлекает данные из очищенного репозитория?

Каковы будут последствия, если я отправлю эти измененные ссылки, а люди будут использовать свою существующую копию, а не создавать новый клон?

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

В частности, то, что происходит на машине этого человека, заключается в том, что команда git pull объединяет старую грязную историю и новую очищенную историю с двумя длинными расходящимися историями (изначально расходящимися с первой «грязной» фиксацией в вашей истории, которая в вашем случае была 3 года назад) были объединены одним совершенно новым и очень запутанным коммитом слияния. Пользователям редко бывает ясно, что это произошло — большинство визуализаторов журналов Git не визуализируют это таким образом, чтобы сделать это очевидным — если вам повезет, пользователь может сказать что-то вроде «У меня есть две копии каждого совершить сейчас, WTF?!" - но только если они действительно наблюдательны.

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

При планировании есть ли способ позволить пользователям сохранить свое старое репо, но обновить его, чтобы иметь очищенную историю?

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

Технически, да. На практике процедура сложна, подвержена ошибкам, и если хотя бы один пользователь ошибается, вы, как и раньше, облажались.

На данный момент мы должны выяснить, почему вы пытаетесь уклониться от этой процедуры. Это потому что:

• Вы пытаетесь избавить пользователей от необходимости знать и иметь дело с историей изменений Git? Похоже, это может быть вашей целью, основываясь на ваших высказываниях "координация между командами может быть невероятно сложно в нашей структуре" - но, к сожалению, это недостижимая цель, потому что Git не позволит вам изменить историю так, чтобы пользователи не заметили. Пользователям придется что-то сделать, и они должны согласовать свои действия с вами.
• Вы хотите сократить время загрузки при создании нового клона вашего действительно огромного репозитория, надеясь, что Git загрузит только измененные большие двоичные объекты, а не все, что не изменилось?< /em> Это немного более разумная цель для гигантских многогигабайтных репозиториев, загрузка которых занимает несколько часов (хотя, если вы используете BFG, чтобы сделать репо намного меньше, мотивации меньше) - к сожалению, из-за деталей протокола Git. вы не сможете воспользоваться этими преимуществами. Протокол Git предназначен для определения того, какие коммиты находятся на удаленном сервере, которых нет в вашем локальном репозитории, и отправки адаптированного файла пакета, содержащего только то, что вам нужно для обновления вашего локального репо. Это здорово, но обратите внимание, что единицей сравнения является фиксация. Когда вы переписываете историю, дерево файлов коммитов практически не меняется, но идентификаторы коммитов все меняются, потому что идентификатор коммита является хэшем его родительского history, а также содержимое файлового дерева. Протокол Git сравнивает только идентификаторы коммитов, и все они разные, поэтому будут отправлены все коммиты, вместе с их объектами файлового дерева. Протокол не копает достаточно глубоко, чтобы понять, что ему не нужно отправлять большую часть этих объектов файлового дерева, и поэтому вы не получаете выгоду от того, что их копии уже есть в вашем локальном репо.