Недавно я работал над задачей обновить сертификат для приложения NodeJS. Последний раз это касалось два года назад для улучшения функции. Любая действующая проблема, возникающая в этом приложении, требует немедленного внимания, хотя приложение использовалось только для внутренних целей.

Приложение старое. Модули Core-NodeJS-Infra не обновлялись более двух лет. Последующие сервисы устарели. Изменился способ вызова нижестоящих сервисов. Жесткие сроки - вишенка на торте. Я знал, что это будут американские горки.

Я потратил три дня на запуск приложения.

Инфра-модули обновлены? Проверять.

Последующие сервисы работают нормально? Проверять.

UI потоки работают нормально? Проверять.

Один из членов нашей команды коснулся приложения для обновления более года назад. Он указал, что репо, из которого я получил разветвление, само по себе является разветвленным репо. Другая команда работала над этим репо, а затем наша команда работала над исходным репо с этого момента, но член моей команды не знает, с какого момента и дальше. Так что это было немного беспорядочно!

У нас есть инструмент «Право собственности», который показывает правильное репо и «солгал» мне. Итак, ситуация была такой:

Да, это был Forkception! WTF и FML были первыми двумя мыслями, которые вылетели у меня из уст. Мне следовало поработать над живым репо, но вместо этого я работал над устаревшим форком. Как я глуп!

Первая мысль - мои три дня работы потрачены зря, и мне нужно начинать все сначала.

Вторая мысль? Позвольте мне спросить моего старого друга Гито. Он очень давно мне помогает.

Я - «Эй, Гит? У меня серьезные проблемы, и мне нужна ваша помощь в решении этой проблемы ».

Git - Эй! Итак, мы должны начать с того, что сейчас идет вживую. Создайте новую ветку под названием upgrade и укажите в этой ветке действующий код. Для этого можно использовать «git hard reset ».

Я - «Хорошо, я сделаю».

На данный момент ситуация выглядит так.

Git - «Нам нужно знать, что изменилось между разработкой и обновлением. Можете ли вы перечислить файлы, которые различаются между обновлением и разработкой? Проверьте эти файлы по отдельности и выясните, какие там были изменения ».

Я - «Круто. Я вижу три вида изменений. Есть услуга S1, которую мне нужно вызвать по-другому. Есть служба S2, которую мне нужно вызвать, используя другую конечную точку. Есть сервис S3, который мне нужно вызвать с разными параметрами. Я также вижу, что файл package.json в ветке upgrade содержит уже обновленные некоторые пакеты. Так что нужно изменить только несколько пакетов ».

Git - «Замечательно, что вы разделили изменения. Теперь покажите мне журнал Git вашей ветки develop. Надеюсь, вы следовали некоторым базовым практикам Git, например, всегда имея код для сборки в каждой фиксации. Сообщение фиксации должно отображать то, что вы изменили ».

Я - «Да, у меня всего четыре коммита в ветке develop. Один коммит был сделан для того, чтобы сделать проект пригодным для сборки. По одному на каждый из трех сервисных вызовов. ”

Git - Отлично! Похоже, вы правильно следовали лучшим практикам. Давайте начнем со стабилизации сборки проекта, обновив package.json. Перейдите в ветку upgrade и сделайте копию package.json - package-copy.json. Теперь, используя Git «replace, обновите / package.json на develop / package.json и запустите разницу между package.json и package-copy.json. Поскольку в действующем коде некоторые пакеты уже изменены и имеются разные версии, вам нужно будет выполнить обновление, просмотрев разницу ».

Я - «Дай мне попробовать. Хорошо, он строится и работает ».

Git - Отлично! Теперь поработаем со служебными вызовами. Я вижу, что у вас есть одна фиксация для каждого изменения вызова службы в ветке разработки. Время «сорвать вишню. Выберите от наименее сложного сервисного вызова до самого сложного сервисного звонка. Выбирайте, объединяйте и разрешайте конфликты. Обязательно проверяйте, находится ли проект в состоянии сборки после каждого выбора и перед каждым коммитом ».

Я - «S1 готов. S2 сделано. S3 сделано. Спасибо, Гит »

Git - «Пожалуйста. Но именно вы помогли себе, следуя практике коммитов Git, а не рассматривая Git как простое хранилище кода ».

Что я здесь делал? 🤔

Зафиксировать связанные изменения

Сделайте паузу и подумайте, должно ли это изменение войти в этот коммит. Фиксация, в которой говорится, что «change: service-s1 endpoints» и есть изменения service-s2, просто создаст путаницу.

Не выполняйте недоделанную работу

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

Однако я лично сжимаю свои небольшие коммиты, используя интерактивный режим git rebase. Это помогает мне иметь одно логическое изменение, которое можно сертифицировать, а также помогает доверенному коммиттеру проверять ваш код. Это намного предпочтительнее для масштабных проектов.

Проверьте свой код перед фиксацией

Мы должны думать о Git как о машине состояний, и любая машина должна быть в состоянии сборки в любом состоянии.

Напишите хорошие сообщения о фиксации

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

Заключение

Мне удалось быстро разрешить беспорядок. Я мог выйти из этого момента WTF и FML только потому, что следовал некоторым хорошим практикам. Они существуют по какой-то причине и подобны соли в пище - вы понимаете их ценность только тогда, когда они не используются.

Ошибки рано или поздно произойдут бессознательно. Но убедитесь, что вы сознательно следуете некоторым практикам, связанным с Git.

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

Это помогает быть уверенным, что после каждой фиксации ваш проект может быть собран, что действительно полезно.

VSCode плохо поддерживает Git. Становится очень легко увидеть конфликты и разрешить их, иногда всего одним щелчком мыши. См. Пример ниже 👇

использованная литература

Особая благодарность моим друзьям Саураб Раджани и Аниш Дхаргалкар, которые помогли мне с уточнением содержания.