Как лучшие практики Git спасают от переработки

Недавно я работал над задачей обновления сертификата для приложения NodeJS. Последнее обновление было 2 года назад. Приложение устарело. Модули Core-NodeJS-Infra не обновлялись, а службы переадресации устарели. и сроки работы над задачей были очень ограничены. Все это можно было сравнить с поездкой на американских горках.

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

Обновлены ли Infra-модули?

Все службы работают нормально?

Потоки пользовательского интерфейса работают нормально?

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

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

Я должен был работать в реальном репо, но вместо этого я работал над другой веткой. Как же глупо!

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

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

Я — “Привет, Git! Я в полной… в общем, у меня проблема, и мне нужна помощь!”

Git — “Привет, не беда! Создай новую ветку и назови upgrade, и добавь в нее работающий код. Для этого можешь использовать git hard reset.

Я — “Попробуем.”

Ситуация стала выглядеть так:

Git — “Нам нужно знать, что изменилось между разработкой и обновлением. Можем ли перечислить файлы, которые отличаются между upgrade и develop? Проверь эти файлы по отдельности и выясни, какие изменения произошли.”

Я — “Круто. Я вижу три вида изменений. Есть сервис S1, который мне нужно вызвать по-другому. Есть сервис S2, который мне нужно вызвать с использованием другой конечной точки. Есть сервис S3, который мне нужно вызвать с использованием разных параметров. Я также вижу, что файл package.json в ветке обновления имеет некоторые из уже обновленных пакетов. Поэтому нужно изменить только несколько пакетов.”

Git — “Здорово, что ты разделил изменения. Теперь покажи мне журнал Git твоей ветки. Надеюсь, ты следовал некоторым базовым практикам Git. Например, в каждом коммите у тебя код, который билдится”.

Я — “Да, у меня есть всего четыре коммита в ветке develop. Один из коммитов делает проект рабочим.”

Git — “Прекрасно! Похоже, ты правильно следовал лучшим практикам. Начнем со стабилизации сборки проекта с создания пакета.json up-to-date. Зайдите в ветку upgrade и сделайте дубликат package.json и package-copy.json. Теперь, используя Git replace, upgrade/package.json с develop/package.json, и запустите diff между package.json и package-copy.json.

Я — “Сейчас попробую. Хорошо, всё билдится и работает.”

Коммитьте только связанные изменения

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

Не коммитьте половину работы

Знакома фраза “коммитьте как можно скорее, коммитьте часто”? Однако это не всегда полезно. Во всем должна быть последовательность и логика. Если с вашим кодом будет работать другой человек, будет ли ему полезна наполовину сделанная работа? Нет.

Тестируйте код перед коммитами

Не забывайте, что Git - это машина, как любая машина, он должен быть рабочим всегда.

Пишите хорошие комментарии к коммитам

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

Заключение

Ошибки случаются у всех. Git наведет порядок в вашей работе. Я поклонник сообщений Git semantic commit, которые помогают отслеживать историю в Git. Согласитесь, вы не можете ожидать от других качественных комментариев к каждому коммиту, но вы можете отслеживать тип сообщений.

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

Перевод статьи How Git best practices saved me hours of rework от Digital Skynet