Hotfix Branch: co to jest, jak tworzyć i stosować w rozwoju aplikacji mobilnych

Co to jest Hotfix Branch?

Hotfix Branch — to tymczasowa gałąź w Git, która jest tworzona w celu szybkiego naprawiania krytycznych defektów w działającym środowisku produkcyjnym. W przeciwieństwie do gałęzi feature, które odgałęziają się od develop i żyją kilka dni lub tygodni, hotfix jest tworzony z main/master i istnieje dokładnie tak długo, jak potrzeba do naprawienia błędu.

Głównym zadaniem hotfix jest minimalizacja czasu między wykryciem krytycznego błędu a jego naprawą na produkcji. Zespół nie czeka na zakończenie bieżącego sprintu lub cyklu wydawniczego, tylko wypuszcza poprawkę natychmiast. Jest to szczególnie ważne w przypadku aplikacji mobilnych, gdzie krytyczny błąd może zablokować użytkowników i doprowadzić do odpływu.

Według danych Google Play Console, średni czas moderacji aktualizacji w Google Play wynosi od 2 do 24 godzin. Dla App Store ekspresowy przegląd może zająć od 1 do 4 godzin. Gałęzie hotfix pozwalają przygotować poprawkę jeszcze przed zakończeniem moderacji i wdrożyć ją natychmiast po zatwierdzeniu.

Zasada działania Hotfix

Proces hotfix składa się z trzech kroków: utworzenie gałęzi z main, wprowadzenie poprawki i scalenie z powrotem do main i develop. Kluczowa różnica w stosunku do zwykłej naprawy — hotfix jest zawsze scalany z obiema gałęziami, aby poprawka nie została utracona przy następnym wydaniu.

Zespół nie powinien dodawać do hotfix nowej funkcjonalności ani refaktoryzować. Tylko konkretna poprawka, minimalnie niezbędna do usunięcia krytycznego problemu. Każde odstępstwo od tej zasady zwiększa ryzyko regresji i wydłuża czas wypuszczenia poprawki.

Kiedy potrzebny jest Hotfix

Hotfix jest niezbędny w trzech scenariuszach: krytyczny błąd blokuje użytkowników (crash, utrata danych), luka w zabezpieczeniach wymaga natychmiastowego zamknięcia lub zepsuta jest krytyczna logika biznesowa (płatności, autoryzacja). Jeśli błąd nie jest krytyczny — można go naprawić w ramach zwykłego cyklu wydawniczego przez develop.

Dla aplikacji mobilnych hotfix może również obejmować zmiany serwerowe, jeśli architektura pozwala na zdalne przełączanie funkcji (feature flags). W takim przypadku gałąź hotfix może być minimalna lub w ogóle niepotrzebna, jeśli poprawka jest wykonywana po stronie serwera.

Modele rozgałęzień i miejsce Hotfix

Nie wszystkie modele rozgałęzień obsługują gałęzie hotfix. Tradycyjny Git Flow przewiduje hotfix jako pełnoprawny typ gałęzi, a nowocześniejsze podejścia (GitHub Flow, Trunk-based) rozwiązują zadanie awaryjnych napraw inaczej.

Git Flow i Hotfix

Git Flow — to jedyny model, w którym hotfix jest wbudowanym typem gałęzi obok feature i release. W Git Flow hotfix jest tworzony z main, a po zakończeniu scalany zarówno z main (z tagiem wersji), jak i z develop. Gwarantuje to, że poprawka nie zostanie utracona w następnym wydaniu.

GitHub Flow i Trunk-based

GitHub Flow nie używa oddzielnego typu gałęzi dla hotfix. Zamiast tego programista tworzy zwykłą gałąź feature z main, wprowadza poprawkę i otwiera Pull Request. Po przeglądzie i testach CI gałąź jest scalana z main i natychmiast wdrażana. Zaletą jest prostota, wadą — brak oddzielnego kanału dla pilnych napraw.

Trunk-based rozwiązuje zadanie hotfix przez bezpośrednie commity do main (w krytycznych przypadkach) z obowiązkowym przeglądem post factum. To podejście wymaga wysokiej dyscypliny zespołu i niezawodnych automatycznych testów, ponieważ zmiany trafiają do produkcji natychmiast.

Jak utworzyć Hotfix Branch

Tworzenie hotfix zaczyna się od przełączenia się na główną gałąź i utworzenia nowej gałęzi z prefiksem hotfix/. Rozważmy proces krok po kroku na przykładzie naprawy krytycznego błędu w aplikacji mobilnej.

Tworzenie gałęzi z main

Pierwszy krok — przełącz się na main i upewnij się, że gałąź jest aktualna. Następnie utwórz gałąź hotfix z czytelną nazwą odzwierciedlającą istotę naprawy.

# Przełącz się na main i pobierz najnowsze zmiany
git checkout main
git pull origin main

# Utwórz gałąź hotfix
git checkout -b hotfix/crash-on-login

Po utworzeniu gałęzi można wprowadzić poprawkę. Ważne: hotfix powinien zawierać minimalną liczbę zmian. Nie należy refaktoryzować kodu ani dodawać nowych możliwości — tylko konkretna poprawka, która usuwa problem.

Zatwierdzenie poprawki

Commit w hotfix powinien mieć informacyjną wiadomość, która jednoznacznie opisuje problem i jego rozwiązanie. Format: typ(obszar): krótki opis + link do zadania w trackerze.

# Dodaj zmodyfikowane pliki
git add src/ui/login/LoginActivity.kt

# Utwórz commit z opisem
git commit -m "fix(login): handle null intent on activity resume

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

Wiadomość commita powinna zawierać opis problemu i link do zadania. Upraszcza to wyszukiwanie w historii i pomaga współpracownikom zrozumieć, co zostało naprawione i dlaczego. W projektach mobilnych zwykle podaje się również wersję aplikacji, w której wykryto błąd.

Scalenie z main i develop

Ostatni krok — scal hotfix z powrotem z main (z tagiem nowej wersji łatki) i z develop (aby poprawka została zachowana w następnym wydaniu). Najpierw tworzone jest scalenie z main z tagiem, następnie scalenie z develop.

# Scal do main i utwórz tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Scal do develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Wyślij zmiany na serwer
git push origin main --tags
git push origin develop

Flaga --no-ff gwarantuje utworzenie commita scalenia, nawet jeśli hotfix można by zastosować przez fast-forward. Zachowuje to informację o tym, że wykonano awaryjną naprawę, i upraszcza analizę historii w przyszłości.

Różnica między Hotfix a Feature i Release

Hotfix zasadniczo różni się od gałęzi feature i release pod względem celu, czasu życia i zasad scalania. Zrozumienie tych różnic jest kluczowe dla prawidłowej organizacji procesów Git w zespole.

Gałąź feature jest przeznaczona do nowej funkcjonalności. Żyje od kilku dni do kilku tygodni, tworzona jest z develop i scalana z powrotem do develop. Feature może zawierać wiele commitów, w tym eksperymentalnych, które później są ściskane przez squash lub rebase.

Gałąź release przygotowuje wydanie do publikacji. Tworzona jest z develop, w niej naprawiane są błędy znalezione podczas stabilizacji i nie przyjmuje nowej funkcjonalności. Po zakończeniu release jest scalana z main (z tagiem) i develop.

Hotfix natomiast jest tworzony i scalany bezpośrednio z main, z pominięciem develop (choć po naprawie synchronizuje się również z develop). Zawiera minimalną liczbę zmian i istnieje minimalny czas. Jeśli feature lub release można odłożyć do następnego cyklu, hotfix — nie.

Dla rozwoju aplikacji mobilnych to rozróżnienie jest szczególnie ważne: App Store i Google Play pozwalają wypuszczać wersje łatki oddzielnie od głównych wydań. Gałąź hotfix zapewnia proces, w którym wydanie łatki nie miesza się z niedokończonymi funkcjami.

Typowe błędy przy pracy z Hotfix

Błędy przy pracy z hotfix mogą zniweczyć zalety awaryjnej naprawy. Rozważmy pięć najczęstszych problemów, które występują w zespołach używających Git Flow.

• Tworzenie hotfix z develop — jeśli hotfix jest tworzony z develop, do łatki mogą trafić niedokończone funkcje. Hotfix powinien być tworzony tylko z main, aby zagwarantować, że w poprawce znajduje się tylko stabilny kod.
• Kilka napraw w jednym hotfix — każda naprawa powinna być w osobnej gałęzi hotfix. Mieszanie kilku błędów w jednej gałęzi utrudnia przegląd kodu, zwiększa ryzyko regresji i utrudnia wycofanie w razie potrzeby.
• Pominięcie scalenia z develop — jeśli hotfix nie zostanie scalony z develop, poprawka zostanie utracona przy następnym wydaniu. Zespół odkryje, że ten sam błąd pojawił się ponownie i będzie zmuszony naprawiać go ponownie.
• Nieprawidłowy tag wersji — hotfix powinien otrzymać inkrementację łatki (v2.3.0 → v2.3.1), a nie minor (v2.4.0) lub major (v3.0.0). Naruszenie semantycznego wersjonowania zaburza system budowania i dezorientuje użytkowników.
• Brak kontroli CI — nawet awaryjny hotfix powinien przechodzić automatyczne testy. Pominięcie CI zwiększa ryzyko wprowadzenia nowego błędu. Zaleca się posiadanie oddzielnego pipeline dla gałęzi hotfix z przyspieszonymi kontrolami.

Każdy z tych błędów prowadzi do opóźnienia wydania łatki lub do pojawienia się nowych problemów w produkcji. Zespoły powinny ustalić zasady pracy z hotfix w CONTRIBUTING.md i zautomatyzować je przez kontrole CI/CD.