Как мне начать использовать Git для разных баз кода на разных серверах?

Предыстория: я недавно унаследовал ряд проектов в своей компании, и я пытаюсь разобраться в некоторых фундаментальных проблемах с их обработкой. А именно, предыдущие разработчики (которые больше не работают в компании) не использовали какой-либо формы контроля версий, создавали мало документации и на самом деле не имели хороших процессов разработки.

Так что теперь у меня есть три сервера проектов (разработка, подготовка, производство), которые состоят в основном из веб-сайтов, приложений и инструментов, созданных для сторонних приложений и 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. Как только это будет сделано, все ветви должны содержать один и тот же код, и любая разработка, выполненная на рабочем сервере, теперь переносится обратно на «сервер» разработки.

В этой модели каждый проект будет иметь свое собственное репо, и у этого репо будет ветвь masterand develop, плюс 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теперь содержит все изменения из каждой среды. Теперь вы можете переключиться на любую подходящую модель ветвления.

Это хорошая идея, чтобы иметь историю. Я бы создал хранилище (или по одному для каждого продукта) из наиболее стабильной среды. Создание веток или различий для других.

На высоком уровне:

1. Создать новый репо
2. Из рабочей рабочей копии: добавьте все, подтвердите и отправьте
3. Оформить заказ мастеру в новый каталог
4. Для каждой дополнительной среды XYZ
   1. Создать ветку Archive-XYZ
   2. Замените все с XYZисточником (кроме .git)
   3. добавить все, зафиксировать и нажать

В качестве альтернативы, если вы скептически относитесь к значению этого, git diff > XYZ.diffвместо фактической фиксации и нажатия и архивирования различий.

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