Як почати використовувати Git для різних баз коду від різних серверів?

Передумови: Нещодавно я успадкував набір проектів у своїй компанії і намагаюся розібратися з основоположними питаннями щодо того, як вони впоралися. А саме, попередні розробники (які вже не є компанією) не використовували жодної форми управління джерелами, мало документації та насправді не мали належних процесів розробки.

Отож, у мене зараз є три проекти на серверах (розробка, постановка, виробництво), які складаються здебільшого веб-сайтів та додатків та інструментів, створених для сторонніх додатків та API, які ми використовуємо, аж до магазинів сценаріїв SQL та інших речей. Моя перша думка полягала в тому, щоб все це перетворити в Git до того, як будуть внесені зміни та виправлення, але мені важко з’ясувати найкращий спосіб зробити це.

Багато попередніх розробок було зроблено безпосередньо на виробничих серверах, що створило розрив між кодовою базою кожного сервера. Не відразу зрозуміло, у чому полягають усі відмінності - я бачу виправлення помилок на виробничій стороні, які не переносяться на розробку / інсценізацію, а також нові функції в розробці, які не були спрямовані на постановку / виробництво .

Питання: Що було б для мене найкращим способом організації та переміщення в Git? Як я можу структурувати свої репозиції / відділення, щоб вони відповідали відмінностям у коді?

Я розглянув продовження розробки з клонів коду виробничого сервера та збереження баз коду розробки / постановки як історичну орієнтир. Можливо, це може бути точково для початку, враховуючи, що я нічого не знаю про код розробки / постановки? Я міг би просто створити репозиції виробничих серверів для кожного веб-сайту, інструменту, набору скриптів тощо, створити гілки для існуючого коду розробки / постановки, і будь-яка нова розробка буде відділятися від кодової бази виробничого сервера. Це має сенс?

Висуньте виробничі речі у 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і developгалузь, і плюс feature_branchesдля будь-якої роботи, що проводиться.

EDIT, щоб вирішити коментарі: Так, це Gitflow.

Ця стратегія (або Gitflow взагалі) підтримує існуючу 3-рівневу систему (виробництво, постановка, розвиток) з чітким шляхом злиття від розвитку вгору до виробництва. Імпорт баз коду таким чином також дозволяє синхронізувати гілки, зберігаючи статус-кво у виробництві - принаймні, до тих пір, поки злиття не зможуть перевірити. Це досягає декількох цілей: отримує код у керуванні джерелом, синхронізує та об'єднує різні бази кодів (тому більше немає помилок у виробництві, але не в розробці) та забезпечує приємний процес для використання вперед (процес, який добре визначений і використовується багатьма людьми / командами / компаніями. Якщо ОП виявить, що Gitflow недостатньо підходить для його проектів / команд / компанії, коли він використовує / компанія зростає, то це '

* Ви можете вирізати ще одну особливість гілки і видалити будь-які очевидні нові можливості, і об'єднати цю гілку в develop(а потім і в master). Це не дає вам тестувати нові функції поверх усіх інших тестів, які ви будете робити.

Я рекомендую цей stagingкод як найкращу базову лінію для вашого початкового імпорту. Це тому, що є зміни в productionцьому немає staging, через гарячі виправлення, але набагато менше, якщо будь-яких змін у stagingцьому немає production. Так само є зміни development, яких немає staging, завдяки новим функціям, але, ймовірно, набагато менше, якщо будь-яких змін у stagingцьому немає development.

Зауважте, ви не бажаєте stagingбути базовою лінією після першого імпорту. Це лише тимчасова ситуація через зміни, які не відслідковувались раніше. Операції з філіями йдуть набагато плавніше, якщо ви додаєте зміни, а не видаляєте їх. Після першого імпорту перейдіть до тієї моделі розгалуження, яка найкраще відповідає вашим потребам.

Отже, перевірте свій stagingкод у stagingфілію, потім зробіть git checkout -b master stagingдля створення своєї masterфілії та перевірте свій виробничий код. Потім зробіть, 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замість того , щоб насправді здійснювати та натискати, і архівуйте розріз.

Так чи інакше, ви повинні закінчитись у стані, коли ви зможете легко порівняти код, який ви працюєте, у кожному середовищі, який ви можете використовувати для поселення на одній початковій точці для кожного проекту. І якщо щось порушиться, ви теоретично зможете порівняти свої зміни з будь-яким із трьох середовищ.