{"id":13585,"url":"\/distributions\/13585\/click?bit=1&hash=5abbdccc3fb020b5689ad8081fa009393de3b75c1e378f7f15bf1276f341927b","title":"\u0421\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u0432\u0438\u0434\u0435\u043e\u0437\u0432\u043e\u043d\u043a\u043e\u0432 \u0441 \u0438\u043d\u0442\u0435\u043b\u043b\u0435\u043a\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u043c \u0448\u0443\u043c\u043e\u043f\u043e\u0434\u0430\u0432\u043b\u0435\u043d\u0438\u0435\u043c","buttonText":"\u0413\u0434\u0435 \u0432\u0437\u044f\u0442\u044c?","imageUuid":"d9c50f1f-3071-518e-8ae7-e283eb318898","isPaidAndBannersEnabled":false}
Сервисы
Digital Skynet

Как лучшие практики 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. Так проще видеть конфликты и разрешать их, иногда всего лишь одним щелчком мыши. Как в примере ниже.

0
4 комментария
Александр Ерёмин

Ну и зачем оно тут, если есть хабр?

Ответить
Развернуть ветку
Pavel Ivanov

На Хабре это схватило бы 100500 минусов и никогда не вышло из песочницы. А здесь можно с гордостью писать: "Хабр уже не торт. Все мои бородатые друзья-хакеры оттуда ушли. Я держался до последнего."

Ответить
Развернуть ветку
Макс Мухарёв

Хабр уже не торт 😏

Ответить
Развернуть ветку
Kirill Pankin

o_O

Ответить
Развернуть ветку
Читать все 4 комментария
null