Ищите предложения по git-workflow при работе с огромным PHP-проектом обновления
В течение последних нескольких месяцев я работал над масштабным проектом обновления 11-летнего приложения, которое состоит из более чем 3500 отдельных файлов. В какой-то момент файлы были скопированы (ими управлял SVN, затем...), и началась работа по конвертации параллельно с продолжением работы по поддержке клиента.
В репозитории преобразования (который полностью не связан с "другим" Git-репозиторием, который вытеснил SVN), было выполнено около 314 коммитов, и некоторые из них являются гигантскими. (Преобразование <? в <?php, замена mysql_ звонки с вызовами в интерфейсную библиотеку и тд.)
Теперь задача состоит в том, чтобы перенести в этот файл около 120 файлов, которые изменились в "другом" репо (который в конечном итоге должен быть заброшен...). До сих пор мой подход заключался в создании ветви, копировании файлов в эту новую ветку и повторном применении "базовых" изменений, таких как описанные выше, с использованием инструментов автоматического анализа кода, которые я разработал для этой цели.
И здесь я не уверен, что делать дальше. Я хочу повторно внести изменения, которые я внес в эти файлы, как это отражено в 300 с лишним коммитах, которые сейчас выполняются в основной ветви моего конверсионного репо, и сделать это как можно скорее автоматически. У меня есть файл, который содержит список всех файлов, о которых идет речь. Моя мысль cherry-pick некоторые из старых коммитов выходят из основной ветки и применяют их к файлам в новой ветке (которые никогда не могут быть объединены с главной веткой ). На мой взгляд, только те коммиты, которые касаются любого из этих файлов, должны быть повторно применены. (Но некоторые из этих коммитов затрагивали тысячи файлов, в том числе, но не ограничиваясь теми, что находятся здесь.)
На данный момент я стою на пороге решения, еще ничего не сделав, и не совсем уверен, как лучше поступить.
Помните: есть два отдельных git репо, но они совершенно не связаны с другим. (Тот, который использовался для сопровождения производства, в то время даже не существовал.) Так что я могу использовать его... и, действительно, использовал его... только для получения списка файлов, к которым были произведены прикосновения, и для получения их самая последняя версия. Когда проект конвертации будет завершен, репо-конверсия будет отброшена, а текущее репо-решение будет заморожено. Будет создан совершенно новый репо, чтобы двигаться вперед.
Совет искренне искал.,,
РЕДАКТИРОВАТЬ: С тех пор я рассмотрел совершенно другой подход, который будет отказаться от курса, который я начал, полностью отбросить эту ветку, и следовать другой стратегии прохождения старого репо, захвата выбранных коммитов в качестве патчей и попытки применить эти патчи для существующих (хотя, возможно, очень измененных) модулей. Или, если нужно, делать то же самое вручную. Только около 100, "дай или возьми", обязуется сделать... Комментарии сердечно (и искренне) запрашиваются по любой стратегии.
1 ответ
Я не уверен, что это именно то, что вы ищете, но мое предложение будет использовать Gitflow Workflow.
Как это работает, у вас есть основная ветка под названием master где основной код существует. Этот код всегда является последним стабильным кодом для проекта.
Рядом с этой веткой develop ветка. Эта ветвь содержит весь прогресс развития. Дополнительные функции могут быть разветвлены от develop и вернули в более позднее время, когда они закончили. Исправления также могут быть разветвленными от develop, В вашей ситуации вы можете develop ветвь для каждой из ваших миграций, то есть добавление одной функции за раз.
Когда develop ветка стабильна и пришло время для выпуска, вы можете затем объединить develop ветвь с master, Я использовал этот тип рабочего процесса для некоторых из моих крупных проектов, и он мне очень помог.
Ниже приведена схема, которая показывает, как может выглядеть этот тип рабочего процесса. Круги отмечены цветной легендой. Если у вас есть какие-либо вопросы или вам нужна дополнительная информация от меня, пожалуйста, не стесняйтесь, дайте мне знать.
