Алгоритм решения задачи и багфикса: полный цикл и ветвление в Git
Хаос в разработке начинается не в коде, а в голове: непонятно, с чего начать, от какой ветки ответвляться и можно ли катить правку сразу на прод. Ниже — спокойный, повторяемый алгоритм. Он одинаково работает и для новой фичи, и для рутинного бага, и для «горящего» инцидента на проде. Идея простая: сначала понять задачу, потом выбрать тип работы, и только потом трогать код.
Шаг 0. Понять задачу (до единой строки кода)
Самая дорогая ошибка — начать писать код, не поняв проблему. Прежде чем открывать редактор, ответьте себе на вопросы:
- Что именно нужно? Сформулируйте задачу одним предложением. Если не получается — задача ещё не понята.
- Как я пойму, что готово? Критерии приёмки: что должно работать, какой результат считается верным.
- Где это в коде? Найдите место (файл, функцию, модуль), которое нужно менять. Поиск по проекту экономит часы.
- Что может сломаться рядом? Какие части системы зависят от этого кода.
Для бага добавляется обязательный пункт — воспроизвести. Баг, который вы не можете повторить, вы не можете и починить (а только угадать). Зафиксируйте шаги воспроизведения:
1. Что сделал пользователь (шаги).
2. Что он ожидал увидеть.
3. Что увидел на самом деле (ошибка, лог, скриншот).
4. Где воспроизводится: прод / тест / только локально.Шаг 1. Определить тип работы
От типа работы зависит всё: от какой ветки ответвляться, насколько тщательно тестировать и как быстро катить. Различают три основных типа.
Фича (feature) — новая функциональность
Новый раздел, форма, кнопка, интеграция. Не срочно, можно делать спокойно
и с ревью. Ответвляется от ветки разработки (dev или
main, если модель простая).
Фикс (fix) — обычное исправление бага
Что-то работает не так, но мир не рушится: кривая вёрстка, неверный текст, ошибка в редком сценарии. Идёт тем же путём, что и фича — через ветку разработки и обычный релиз.
Хотфикс (hotfix) — срочная правка прода
На проде сломалось что-то важное прямо сейчас: упала оплата, белый
экран, утечка данных. Ждать следующего релиза нельзя. Хотфикс ответвляется
от продакшен-ветки (main/master),
а не от dev — потому что в dev уже лежат недоделанные
фичи, которые на прод выкатывать нельзя.
Главный критерий хотфикса — «горит на проде». Если не горит, это обычный фикс, и спешка только добавит новых багов.
Шаг 2. Блок-схема: куда ветвиться
Чтобы не гадать каждый раз, прогоните задачу через простую схему принятия решения:
┌─────────────────────────────┐
│ Появилась задача / баг │
└──────────────┬──────────────┘
│
┌───────────────▼────────────────┐
│ Прод сломан и ждать нельзя? │
└───────┬───────────────┬────────┘
да │ │ нет
▼ ▼
┌──────────────────┐ ┌─────────────────────────┐
│ HOTFIX │ │ Это новый функционал? │
│ ветка от main │ └──────┬──────────────┬───┘
└────────┬─────────┘ да │ │ нет
│ ▼ ▼
│ ┌──────────────┐ ┌──────────────┐
│ │ FEATURE │ │ FIX (баг) │
│ │ ветка от dev │ │ ветка от dev │
│ └──────┬───────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────────────────────┐
│ merge → main │ │ merge → dev → тест → релиз→main │
│ + обратно в dev│ └────────────────────────────────┘
└────────────────┘
Ключевой нюанс хотфикса: после выката на прод его обязательно нужно
влить обратно в dev, иначе в следующем релизе
починенный баг «вернётся» — ведь в ветке разработки правки не было.
Шаг 3. Полный цикл работы над задачей
Когда тип определён, дальше всё идёт по одному и тому же конвейеру. Разница между фичей, фиксом и хотфиксом — только в исходной ветке и в скорости, но не в этапах.
3.1. Создать ветку с понятным именем
Одна задача — одна ветка. Имя ветки говорит, что внутри:
# Новый функционал — от ветки разработки
git switch dev
git pull
git switch -c feature/user-profile-export
# Обычный баг — тоже от dev
git switch -c fix/cart-total-rounding
# Срочная правка прода — ОТ ПРОДАКШЕН-ВЕТКИ
git switch main
git pull
git switch -c hotfix/payment-500-error
Префиксы feature/, fix/, hotfix/ сразу
показывают тип и происхождение ветки — это удобно и людям, и автоматике (CI).
3.2. Писать код маленькими шагами
- Сначала минимально рабочее решение, потом улучшения. Не пытайтесь сделать идеально с первого захода.
- Меняйте только то, что относится к задаче. Заметили другой баг — заведите отдельную задачу/ветку, не тащите в текущую.
- Коммитьте часто и осмысленно. Маленький коммит легко понять и при необходимости откатить.
git add .
git commit -m "fix(cart): round total to 2 decimals"Для бага есть отдельный приём — сначала зафиксировать причину, потом чинить. Полезно временно добавить тест или лог, который воспроизводит баг: увидели, что он падает «как надо», — теперь чините, пока не станет зелёным.
3.3. Проверить у себя (до ревью)
Самопроверка экономит время всем. Минимум перед тем, как показывать код:
- сценарий из задачи действительно работает;
- тот самый баг больше не воспроизводится по исходным шагам;
- ничего соседнего не сломалось (прогон тестов / сборки);
- в диффе нет случайного мусора: отладочных
console.log, закомментированного кода, лишних файлов.
git diff # перечитать собственные изменения свежим взглядом
npm test # прогнать тесты, если они есть
npm run build # убедиться, что проект собирается3.4. Pull Request и ревью
Залейте ветку и откройте Pull Request в целевую ветку
(dev для фич/фиксов, main для хотфиксов).
Хорошее описание PR отвечает на три вопроса: что поменялось,
зачем и как проверить.
git push -u origin feature/user-profile-exportРевьюер смотрит не «нравится/не нравится», а: решает ли код задачу, нет ли очевидных багов, не усложнено ли без нужды. После замечаний — правки в той же ветке, новые коммиты, повторный взгляд.
3.5. Мерж и выкат
После аппрува — мерж. Дальше путь зависит от типа:
- Фича/фикс: мерж в
dev→ проверка на тест-стенде → когда накопился релиз,devвливается вmainи катится на прод. - Хотфикс: мерж в
main→ немедленный выкат на прод → обратный мерж вdev, чтобы правка не потерялась.
3.6. Проверить на проде и закрыть задачу
Выкатили — убедитесь, что на реальном проде всё работает (особенно после хотфикса). Не забудьте про кэш: иногда «не помогло» означает лишь старый закэшированный ассет или страницу. После проверки — закрыть задачу и кратко записать, в чём была причина: будущему себе спасибо.
Отдельно про хотфикс: дисциплина под давлением
Инцидент на проде провоцирует панику и «быстрые» правки прямо на сервере. Это и есть источник новых аварий. Спокойный порядок действий:
- Стабилизировать, потом разбираться. Если есть способ быстро вернуть работоспособность (откат на прошлую версию, фича-флаг, отключение проблемного блока) — сделайте это первым. Откат часто быстрее и безопаснее «героического» фикса.
- Минимальная правка. Хотфикс чинит ровно одну проблему. Рефакторинг и улучшения — потом, отдельной задачей.
- Через ветку и git, а не правкой файлов на сервере. Иначе изменение нигде не сохранится и потеряется при следующем деплое.
- Обратный мерж в
dev. Обязательно — иначе баг вернётся. - Постмортем. Когда пожар потушен — короткий разбор: почему случилось и что сделать, чтобы не повторилось.
Чек-лист на каждый день
[ ] Понял задачу и критерии готовности
[ ] (баг) Воспроизвёл и зафиксировал шаги
[ ] Определил тип: feature / fix / hotfix
[ ] Ответвился от правильной ветки (dev или main)
[ ] Сделал маленькие осмысленные коммиты
[ ] Проверил у себя: работает, не сломал соседнее, дифф чистый
[ ] Открыл PR с описанием «что / зачем / как проверить»
[ ] Прошёл ревью и внёс правки
[ ] Смёрджил и выкатил
[ ] Проверил на проде (+ сбросил кэш при необходимости)
[ ] (hotfix) Влил обратно в dev
[ ] Закрыл задачу и записал причинуИтог
Хороший разработчик отличается не скоростью набора, а порядком в голове. Алгоритм один: понять → классифицировать → ответвиться правильно → сделать малыми шагами → проверить → провести через ревью → выкатить → подтвердить на проде. Разница между фичей, обычным фиксом и хотфиксом — лишь в исходной ветке и в срочности. Запомните главное правило ветвления: фичи и фиксы растут от ветки разработки, хотфиксы — от прода и обязательно возвращаются в разработку. Когда этот цикл становится привычкой, задачи перестают пугать, а прод — падать от случайных правок.