1

Я имею дело с приложением, которое было создано без надлежащей системы управления контентом. Вместо этого исходные файлы были сохранены в ZIP-архив и создавались резервные копии каждый раз, когда была выпущена новая версия.

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

Было бы просто создать репозиторий из самого последнего архива и работать оттуда, но как мне включить историю изменений?

1 ответ1

3

Было бы просто создать репозиторий из самого последнего архива и работать оттуда, но как мне включить историю изменений?

Довольно легко. Есть два способа сделать это в зависимости от того, насколько чиста кодовая база из одного ZIP-архива в другой: накопительный UnZIP-коммит или очистка после каждого коммита.

Кумулятивные коммиты UnZIP: разархивировать, зафиксировать, разархивировать другое, зафиксировать другое и т.д.

Решение состоит в том, чтобы сначала создать репозиторий git на основе самого старого архива, зафиксировать его, затем добавить последующие / прогрессивно новые вещи, зафиксировать это и так далее, и так далее. Например, предположим, у вас есть три архива, которые названы / датированы следующим образом:

  • archive_20150801.zip
  • archive_20150804.zip
  • archive_20150806.zip

Теперь я хотел бы начать с распаковки архива archive_20150801.zip и создания исходного репозитория git на основе этого. Затем я бы распаковал архив archive_20150804.zip и перетащил / скопировал - или просто разархивировал на месте - так, чтобы материал перезаписывал старый archive_20150801.zip и так далее. То же самое с archive_20150806.zip .

Очистить после каждой фиксации: разархивировать, зафиксировать, удалить, разархивировать другую, зафиксировать другую, удалить другую и т.д.

Но если вы хотите быть более точным при объединении новых файлов со старыми файлами в каждом ZIP-архиве, я бы порекомендовал сделать это:

  1. Распакуйте архив и зафиксируйте его.
  2. Затем, после того как эта фиксация сделана, вручную - не через git rm удалите все файлы из каталога, в котором находится репозиторий. Убедитесь, что не удалили специфичные для git вещи, такие как .git , .gitignore и тому подобное.
  3. После этого - и относительно пустого каталога на месте - разархивируйте следующий архив и поместите его содержимое в каталог репозитория git.
  4. Теперь с новыми файлами выполните git add -A и сделайте новый коммит.
  5. После этого вернитесь к первому шагу для следующего ZIP-архива, который вы хотите добавить к миксу.

Преимущество этого метода «фиксировать вещи, удалять вещи, добавлять новые вещи, фиксировать новые вещи» состоит в том, что вы не будете получать случайные файлы, которые могли существовать только в ранней версии кода в конечном репозитории. Каждый коммит является чистым отражением того, что содержит этот ZIP, а не совокупной кучей файлов и каталогов, развернутых друг над другом.

Хранение дат выполнения прямо

Что касается сохранения некоторого подобия истории даты / времени, вы можете сделать некоторую сложную работу и заставить фактические даты принятия мерзавца соответствовать фактическим датам архива, как объяснено в этом ответе переполнения стека. Но я лично нахожу это слишком сложным и подверженным риску; Я предпочитаю, чтобы такие задачи были максимально простыми. Вместо этого я бы установил сообщение о коммите, в котором четко указано, на что похож каждый коммит

Commit 2015-08-01 ZIP релиз архива.

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .