Hotfix Branch: что это, как создавать и применять в мобильной разработке

Что такое Hotfix Branch?

Hotfix Branch — это временная ветка в Git, которая создаётся для оперативного исправления критических дефектов в работающем продакшене. В отличие от feature-веток, которые ответвляются от develop и живут несколько дней или недель, hotfix создаётся от main/master и существует ровно столько, сколько нужно для исправления бага.

Основная задача hotfix — минимизировать время между обнаружением критической ошибки и её исправлением на продакшене. Команда не ждёт завершения текущего спринта или релизного цикла, а выпускает патч немедленно. Это особенно важно для мобильных приложений, где критический баг может заблокировать пользователей и привести к оттоку.

По данным Google Play Console, среднее время прохождения модерации обновления в Google Play — от 2 до 24 часов. Для App Store экспресс-ревью может занять от 1 до 4 часов. Hotfix-ветки позволяют подготовить исправление ещё до того, как пройдёт модерация, и выкатить его сразу после аппрува.

Принцип работы Hotfix

Процесс hotfix состоит из трёх шагов: создание ветки от main, внесение исправления и слияние обратно в main и develop. Ключевое отличие от обычного фикса — hotfix всегда сливается в обе ветки, чтобы исправление не потерялось при следующем релизе.

Команда не должна вносить в hotfix новый функционал или рефакторинг. Только точечное исправление, минимально необходимое для устранения критической проблемы. Любое отклонение от этого правила увеличивает risk регрессии и затягивает время выпуска патча.

Когда нужен Hotfix

Hotfix необходим в трёх сценариях: критический баг блокирует пользователей (crash, data loss), уязвимость безопасности требует немедленного закрытия, или сломана критическая бизнес-логика (платежи, авторизация). Если баг неcritical — его можно исправить в рамках обычного релизного цикла через develop.

Для мобильных приложений hotfix также может включать серверные изменения, если архитектура позволяет переключать фичи удалённо (feature flags). В этом случае hotfix-ветка может быть минимальной или вообще не понадобится, если исправление делается на стороне сервера.

Модели ветвления и место Hotfix

Не все модели ветвления поддерживают hotfix-ветки. Традиционный Git Flow предусматривает hotfix как полноценный тип ветки, а более современные подходы (GitHub Flow, Trunk-based) решают задачу экстренных исправлений иначе.

Git Flow и Hotfix

Git Flow — единственная модель, где hotfix является встроенным типом ветки наравне с feature и release. В Git Flow hotfix создаётся от main, а после завершения сливается и в main (с тегом версии), и в develop. Это гарантирует, что исправление не потеряется в следующем релизе.

GitHub Flow и Trunk-based

GitHub Flow не использует отдельный тип ветки для hotfix. Вместо этого разработчик создаёт обычную feature-ветку от main, вносит исправление и открывает Pull Request. После ревью и проверок CI ветка сливается в main и сразу деплоится. Преимущество — простота, недостаток — отсутствие отдельного канала для срочных исправлений.

Trunk-based разработка решает задачу hotfix через коммиты напрямую в main (для критических случаев) с обязательным ревью постфактум. Этот подход требует высокой дисциплины команды и надёжных автоматических тестов, поскольку изменения попадают в продакшен мгновенно.

Как создать Hotfix Branch

Создание hotfix начинается с переключения на основную ветку и создания новой ветки с префиксом hotfix/. Рассмотрим пошаговый процесс на примере исправления критического бага в мобильном приложении.

Создание ветки от main

Первый шаг — переключиться на main и убедиться, что ветка актуальна. Затем создать ветку hotfix с понятным именем, отражающим суть исправления.

# Переключиться на main и получить последние изменения
git checkout main
git pull origin main

# Создать hotfix-ветку
git checkout -b hotfix/crash-on-login

После создания ветки можно внести исправление. Важно помнить: hotfix должен содержать минимальное количество изменений. Не следует рефакторить код или добавлять новые возможности — только точечное исправление, которое устраняет проблему.

Фиксация исправления

Коммит в hotfix должен иметь информативное сообщение, которое однозначно описывает проблему и её решение. Формат: тип(область): краткое описание + ссылка на задачу в трекере.

# Добавить изменённые файлы
git add src/ui/login/LoginActivity.kt

# Создать коммит с описанием
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

Сообщение коммита должно содержать описание проблемы и ссылку на задачу. Это упрощает поиск в истории и помогает коллегам понять, что было исправлено и почему. Для мобильных проектов также принято указывать версию приложения, в которой обнаружен баг.

Слияние в main и develop

Финальный шаг — слить hotfix обратно в main (с тегом новой патч-версии) и в develop (чтобы исправление сохранилось в следующем релизе). Сначала создаётся merge в main с тегом, затем — merge в develop.

# Слить в main и создать тег
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Слить в develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Отправить изменения на сервер
git push origin main --tags
git push origin develop

Флаг --no-ff гарантирует создание коммита слияния, даже если hotfix можно было бы применить через fast-forward. Это сохраняет информацию о том, что было выполнено экстренное исправление, и упрощает анализ истории в будущем.

Отличие Hotfix от Feature и Release веток

Hotfix принципиально отличается от feature и release веток по цели, времени жизни и правилам слияния. Понимание этих отличий критически важно для правильной организации Git-процессов в команде.

Feature-ветка предназначена для новой функциональности. Она живёт от нескольких дней до нескольких недель, создаётся от develop и сливается обратно в develop. Feature может содержать множество коммитов, включая экспериментальные, которые впоследствии сжимаются через squash или rebase.

Release-ветка готовит релиз к выпуску. Она создаётся от develop, в ней исправляются баги, найденные в процессе стабилизации, и она не принимает новый функционал. После завершения release сливается в main (с тегом) и develop.

Hotfix же создаётся и сливается напрямую с main, минуя develop (хотя после исправления синхронизируется и с develop). Он содержит минимальное количество изменений и существует минимальное время. Если feature или release могут быть отложены до следующего цикла, hotfix — нет.

Для мобильной разработки это различие особенно важно: App Store и Google Play позволяют выпускать патч-версии отдельно от основных релизов. Hotfix-ветка обеспечивает процесс, при котором патч-релиз не смешивается с незавершёнными фичами.

Типичные ошибки при работе с Hotfix

Ошибки при работе с hotfix могут свести на нет преимущества экстренного исправления. Рассмотрим пять наиболее частых проблем, которые возникают в командах, использующих Git Flow.

• Создание hotfix от develop — если hotfix создаётся от develop, в патч могут попасть незавершённые фичи. Hotfix должен создаваться только от main, чтобы гарантировать, что в исправление включён только стабильный код.
• Несколько исправлений в одном hotfix — каждое исправление должно быть в отдельной hotfix-ветке. Смешивание нескольких багов в одной ветке усложняет код-ревью, повышает риск регрессии и затрудняет откат при необходимости.
• Пропуск слияния в develop — если hotfix не слить в develop, исправление будет потеряно при следующем релизе. Команда обнаружит, что тот же баг появился снова, и будет вынуждена исправлять его повторно.
• Некорректный тег версии — hotfix должен получать патч-инкремент (v2.3.0 → v2.3.1), а не минорный (v2.4.0) или мажорный (v3.0.0). Нарушение семантического версионирования сбивает систему сборки и путает пользователей.
• Отсутствие CI-проверок — даже экстренный hotfix должен проходить автоматические тесты. Пропуск CI увеличивает risk внесения новой ошибки. Рекомендуется иметь отдельный pipeline для hotfix-веток с ускоренными проверками.

Каждая из этих ошибок приводит к задержке выпуска патча или к появлению новых проблем на продакшене. Командам стоит зафиксировать правила работы с hotfix в CONTRIBUTING.md и автоматизировать их через CI/CD-проверки.