Будет ли работать «разделение и сшивание» для управления репозиториями GIT с большим количеством файлов?

Question

У нас есть проект, который за многие годы подвергся огромному количеству рефакторинга.Мы почти никогда не оглядываемся назад более 2 месяцев назад, кроме как для развлечения, но, тем не менее, важно сохранять историю проекта.Проблема в том, что это стало стоить нам много времени, когда мы выполняли ежедневные переводы с использованием определенного облачного провайдера.

По этой причине я хотел бы заархивировать весь проект, включая репозиторий GIT иначать новый репо.Или, возможно, просто сотрите все, что старше 2 месяцев, и продолжайте оттуда.

До сих пор это было легко сделать.Но что, если через 2 года я захочу повторить процедуру с резервным копированием всей истории поверх старой истории .

Для иллюстрации:

1. Сейчас:архивировать .git со старым репо 2014-2017
2. Позже: архивировать .git со репо из 2017-2020, но делать это с непрерывностью со старым репо 2014-2017, как будто ничего не произошло.

Цель состоит в том, чтобы сохранить каталог проекта гибким и легким для переноса, но не потерять историю.Если мы хотим, мы всегда должны иметь возможность получить доступ к полной истории где-нибудь непрерывным образом (не отдельным архивам).

Приветствуются другие предложения.

Answer 1

Другой ответ: git-gc.Это на самом деле значительно уменьшает количество файлов (оно уменьшилось с 1100 до 50 с использованием опции --aggressive.

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

Answer 2

Цель состоит в том, чтобы сохранить каталог проекта гибким и легким для переноса, но не потерять историю.Если мы хотим, мы всегда должны иметь доступ к полной истории где-нибудь, непрерывным способом (не отдельными архивами).

Итак, допустим, что ваш существующий репозиторий называется BigRepo.Для того, что вы хотите, я думаю, вы могли бы просто создать клон с именем NewRepo и исключить BigRepo из повседневного использования - заблокировать доступ, чтобы никто не мог напрямую перейти на BigRepo, и только несколько человек могут объединиться.Затем удалите большинство старых коммитов (скажем, что-либо старше двух месяцев) из NewRepo, и пусть все начнут использовать NewRepo.

Это дает вам гораздо меньшее репо, которое меняется ежедневно, и вы по-прежнемухраните все старые коммиты в BigRepo.Время от времени вы можете отправлять запрос извлечения из NewRepo в BigRepo, чтобы все новые коммиты копировались в BigRepo, и вы сохраняете необходимую непрерывную историю.У вас будет абсолютно полная история только в BigRepo сразу после слияния самых новых коммитов из BigRepo, но вы можете объединить новейшие коммиты с BigRepo в любое время, когда вам это нужно.И весь смысл в том, чтобы объединить изменения в BigRepo, чтобы ваши ежедневные резервные копии не длились вечно.