Предыстория: я недавно унаследовал ряд проектов в своей компании, и я пытаюсь разобраться в некоторых фундаментальных проблемах с их обработкой. А именно, предыдущие разработчики (которые больше не работают в компании) не использовали какой-либо формы контроля версий, создавали мало документации и на самом деле не имели хороших процессов разработки.
Так что теперь у меня есть три сервера проектов (разработка, подготовка, производство), которые состоят в основном из веб-сайтов, приложений и инструментов, созданных для сторонних приложений и API, которые мы используем, вплоть до хранилищ сценариев SQL и других вещей. Моей первой мыслью было добавить все это в Git до внесения изменений и исправлений, но мне трудно найти лучший способ сделать это.
Большая часть предыдущих разработок была сделана непосредственно на производственных серверах, что создало разделение между кодами каждого сервера. Не сразу понятно, в чем заключаются все различия - я вижу исправления ошибок на производственной стороне, которые не переносятся на разработку / этапирование, а также новые функции в разработке, которые не были перенесены на этапы / производство ,
Вопрос: Как мне было бы лучше организовать и перенести их в Git? Как бы я структурировал свои репо / ветки, чтобы учесть различия в коде?
Я рассматривал возможность продолжения разработки из клонов кода производственного сервера и сохранения баз кода разработки / промежуточного кода в качестве исторической справки. Возможно, с этого стоит начать, учитывая, что я все равно ничего не знаю о коде dev / staging? Я мог бы просто создать репозитории рабочих серверов для каждого веб-сайта, инструмента, набора сценариев и т. Д., Создать ветки для существующего кода разработки / разработки, и любая новая разработка будет ветвиться из базы кода производственного сервера. Имеет ли это смысл?
источник
Ответы:
Вставьте производственный материал в
master
ветку нового репо. Создайтеdevelop
из этого ветку, а затем объедините в нее промежуточный сервер. Вы можете столкнуться с конфликтами, которые необходимо разрешить. После того, как те будут решены, создать другойfeature_branch
изdevelop
и объединить сервер разработки в него. Разрешите любые конфликты, которые возникают.Это дает вам три ветви, которые представляют вашу производственную, промежуточную среду и среду разработки. Производство ->
master
, постановка ->develop
, разработка ->feature_branch
. Таким образом, вся разработка выполняетсяfeature_branches
и добавляется вdevelop
ветвь только тогда, когда функция выполнена, протестирована и стабильна. Поскольку он стабилен, его можно использовать в качестве постановки. Отрежьтеrelease
ветку от того,develop
когда вы будете готовы к выпуску, свяжите все свободные концы, объедините этоmaster
, и тогда у вас будет новая производственная сборка.Один из ваших первых бизнес-заказов после настройки должен состоять в том, чтобы объединить
feature_branch
обратно вdevelop
*, а затемdevelop
обратно вmaster
. Помните, что онfeature_branch
может содержать непроверенный код и функции, поэтому будьте осторожны при его объединенииdevelop
и затемmaster
. Как только это будет сделано, все ветви должны содержать один и тот же код, и любая разработка, выполненная на рабочем сервере, теперь переносится обратно на «сервер» разработки.В этой модели каждый проект будет иметь свое собственное репо, и у этого репо будет ветвь
master
anddevelop
, плюсfeature_branches
для любой выполняемой работы.РЕДАКТИРОВАТЬ, чтобы адресовать комментарии: Да, это Gitflow.
Эта стратегия (или Gitflow в целом) поддерживает существующую трехуровневую систему (производство, этапирование, разработка) с четким путем слияния от разработки до производства. Таким образом, импорт кодовых баз также позволяет синхронизировать ветви при сохранении статус-кво в производстве - по крайней мере, до тех пор, пока слияния не могут быть проверены. Это решает несколько задач: получает код в системе управления исходным кодом, синхронизирует и объединяет различные кодовые базы (так что больше нет исправлений ошибок в производстве, но не в разработке), и обеспечивается хороший процесс для использования в будущем (процесс, который хорошо определен и используется многими людьми / командами / компаниями). Если ОП находит, что Gitflow не подходит для его проектов / команд / компании, поскольку он использует это / компания растет, тогда это '
* Возможно, вы захотите вырезать другую ветвь функций, удалить любые очевидные новые функции и объединить эту ветвь с
develop
(и затем сmaster
). Это избавляет вас от необходимости тестировать новые функции поверх всех других тестов, которые вы будете выполнять.источник
Я собираюсь рекомендовать
staging
код как лучшую базовую линию для вашего первоначального импорта. Это потому, что есть измененияproduction
, которых нет вstaging
связи с исправлениями, но гораздо меньше, если вstaging
них нет измененийproduction
. Аналогичным образом, есть измененияdevelopment
, которых нет вstaging
связи с новыми функциями, но, вероятно, гораздо меньше, если вstaging
них нет измененийdevelopment
.Обратите внимание, что вы не хотите
staging
быть вашей базовой линией после первоначального импорта. Это просто временная ситуация из-за изменений, которые ранее не отслеживались. Операции ветвления идут намного более гладко, если вы добавляете изменения, а не удаляете их. После первоначального импорта переключитесь на любую модель ветвления, которая больше соответствует вашим потребностям.Итак, проверьте свой
staging
код вstaging
ветке, затем выполните команду a,git checkout -b master staging
чтобы создать своюmaster
ветку, и проверьте там свой рабочий код. Затем сделайте a,git checkout -b development staging
чтобы создать своюdevelopment
ветку, и проверьте там свой код разработки.Теперь проверь свою
development
ветку и погрузисьmaster
в нее. Это позволит вам разрешить огромное количество конфликтов слияний, сохраняяmaster
при этом записи о том, что на самом деле находится в производстве.development
теперь содержит все изменения из каждой среды. Теперь вы можете переключиться на любую подходящую модель ветвления.источник
Это хорошая идея, чтобы иметь историю. Я бы создал хранилище (или по одному для каждого продукта) из наиболее стабильной среды. Создание веток или различий для других.
На высоком уровне:
XYZ
Archive-XYZ
XYZ
источником (кроме .git)В качестве альтернативы, если вы скептически относитесь к значению этого,
git diff > XYZ.diff
вместо фактической фиксации и нажатия и архивирования различий.В любом случае, вы должны перейти в состояние, в котором вы можете легко сравнить код, который вы выполняете в каждой среде, который вы можете использовать, чтобы установить единую отправную точку для каждого проекта. И, если что-то сломается, вы теоретически сможете сравнить ваши изменения с любой из трех сред.
источник