Hotfix Branch: co to je, jak vytvářet a používat v mobilním vývoji

Co je Hotfix Branch?

Hotfix Branch — je dočasná větev v Git, která se vytváří pro operativní opravu kritických defektů v běžící produkci. Na rozdíl od feature větví, které se odvětvují z develop a žijí několik dní nebo týdnů, se hotfix vytváří z main/master a existuje přesně tak dlouho, jak je potřeba k opravě chyby.

Hlavním úkolem hotfix — minimalizovat čas mezi detekcí kritické chyby a její opravou v produkci. Tým nečeká na dokončení aktuálního sprintu nebo cyklu vydání, ale vydává záplatu okamžitě. To je zvláště důležité pro mobilní aplikace, kde kritická chyba může zablokovat uživatele a vést k jejich odchodu.

Podle údajů Google Play Console je průměrná doba moderování aktualizace v Google Play 2 až 24 hodin. Pro App Store může expresní revize trvat 1 až 4 hodiny. Hotfix větve umožňují připravit opravu ještě před dokončením moderování a nasadit ji ihned po schválení.

Princip fungování Hotfix

Proces hotfix se skládá ze tří kroků: vytvoření větve z main, provedení opravy a sloučení zpět do main a develop. Klíčový rozdíl oproti běžné opravě — hotfix se vždy slučuje do obou větví, aby se oprava neztratila při příštím vydání.

Tým by neměl do hotfix přidávat novou funkcionalitu nebo refaktorovat. Pouze cílená oprava, minimálně nezbytná k odstranění kritického problému. Jakákoli odchylka od tohoto pravidla zvyšuje riziko regrese a prodlužuje dobu vydání záplaty.

Kdy je Hotfix potřeba

Hotfix je potřeba ve třech scénářích: kritická chyba blokuje uživatele (pád, ztráta dat), bezpečnostní zranitelnost vyžaduje okamžité uzavření nebo je rozbitá kritická obchodní logika (platby, autentizace). Pokud chyba není kritická — lze ji opravit v rámci běžného cyklu vydání přes develop.

Pro mobilní aplikace může hotfix také zahrnovat změny na serveru, pokud architektura umožňuje dálkové přepínání funkcí (feature flags). V takovém případě může být hotfix větev minimální nebo vůbec není potřeba, pokud se oprava provádí na straně serveru.

Modely větvení a místo Hotfix

Ne všechny modely větvení podporují hotfix větve. Tradiční Git Flow předpokládá hotfix jako plnohodnotný typ větve, zatímco modernější přístupy (GitHub Flow, Trunk-based) řeší problém nouzových oprav jinak.

Git Flow a Hotfix

Git Flow — je jediný model, kde je hotfix vestavěným typem větve vedle feature a release. V Git Flow se hotfix vytváří z main a po dokončení se slučuje jak do main (s tagem verze), tak do develop. To zaručuje, že se oprava neztratí v příštím vydání.

GitHub Flow a Trunk-based

GitHub Flow nepoužívá samostatný typ větve pro hotfix. Místo toho vývojář vytvoří běžnou feature větev z main, provede opravu a otevře Pull Request. Po revizi a CI kontrolách se větev sloučí do main a okamžitě nasadí. Výhoda — jednoduchost, nevýhoda — chybějící samostatný kanál pro naléhavé opravy.

Trunk-based vývoj řeší problém hotfix pomocí přímých commitů do main (pro kritické případy) s povinnou revizí dodatečně. Tento přístup vyžaduje vysokou disciplínu týmu a spolehlivé automatické testy, protože změny se dostávají do produkce okamžitě.

Jak vytvořit Hotfix Branch

Vytvoření hotfix začíná přepnutím na hlavní větev a vytvořením nové větve s prefixem hotfix/. Podívejme se na proces krok za krokem na příkladu opravy kritické chyby v mobilní aplikaci.

Vytvoření větve z main

První krok — přepněte se na main a ujistěte se, že je větev aktuální. Poté vytvořte hotfix větev s jasným názvem odrážejícím podstatu opravy.

# Přepněte se na main a načtěte nejnovější změny
git checkout main
git pull origin main

# Vytvořte hotfix větev
git checkout -b hotfix/crash-on-login

Po vytvoření větve lze provést opravu. Důležité: hotfix by měl obsahovat minimální počet změn. Nerefaktorujte kód ani nepřidávejte nové možnosti — pouze cílenou opravu, která odstraní problém.

Zaznamenání opravy

Commit v hotfix by měl mít informativní zprávu, která jednoznačně popisuje problém a jeho řešení. Formát: typ(oblast): stručný popis + odkaz na úkol v trackeru.

# Přidejte změněné soubory
git add src/ui/login/LoginActivity.kt

# Vytvořte commit s popisem
git commit -m "fix(login): handle null intent on activity resume

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

Zpráva commitu by měla obsahovat popis problému a odkaz na úkol. To usnadňuje vyhledávání v historii a pomáhá kolegům pochopit, co bylo opraveno a proč. U mobilních projektů se obvykle uvádí také verze aplikace, ve které byla chyba nalezena.

Sloučení do main a develop

Poslední krok — slučte hotfix zpět do main (s tagem nové verze záplaty) a do develop (aby se oprava zachovala v příštím vydání). Nejprve se vytvoří sloučení do main s tagem, poté sloučení do develop.

# Slučte do main a vytvořte tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Slučte do develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Odešlete změny na server
git push origin main --tags
git push origin develop

Příznak --no-ff zaručuje vytvoření slučovacího commitu, i když by bylo možné hotfix aplikovat pomocí fast-forward. To zachovává informaci o tom, že byla provedena nouzová oprava, a usnadňuje analýzu historie v budoucnosti.

Rozdíl mezi Hotfix a Feature a Release

Hotfix se zásadně liší od feature a release větví účelem, životností a pravidly slučování. Porozumění těmto rozdílům je klíčové pro správnou organizaci Git procesů v týmu.

Feature větev je určena pro novou funkcionalitu. Žije od několika dní do několika týdnů, vytváří se z develop a slučuje se zpět do develop. Feature může obsahovat mnoho commitů, včetně experimentálních, které se později komprimují pomocí squash nebo rebase.

Release větev připravuje vydání k publikaci. Vytváří se z develop, opravují se v ní chyby nalezené během stabilizace a nepřijímá novou funkcionalitu. Po dokončení se release slučuje do main (s tagem) a develop.

Hotfix se vytváří a slučuje přímo s main, obchází develop (i když se po opravě synchronizuje i s develop). Obsahuje minimální počet změn a existuje minimální dobu. Pokud lze feature nebo release odložit do dalšího cyklu, hotfix — nikoli.

Pro mobilní vývoj je tento rozdíl obzvláště důležitý: App Store a Google Play umožňují vydávat záplaty odděleně od hlavních vydání. Hotfix větev zajišťuje proces, při kterém se vydání záplaty nemísí s nedokončenými funkcemi.

Typické chyby při práci s Hotfix

Chyby při práci s hotfix mohou anulovat výhody nouzové opravy. Podívejme se na pět nejčastějších problémů, které vznikají v týmech používajících Git Flow.

• Vytvoření hotfix z develop — pokud se hotfix vytváří z develop, mohou se do záplaty dostat nedokončené funkce. Hotfix by se měl vytvářet pouze z main, aby bylo zaručeno, že oprava obsahuje pouze stabilní kód.
• Více oprav v jednom hotfix — každá oprava by měla být v samostatné hotfix větvi. Míchání několika chyb v jedné větvi komplikuje revizi kódu, zvyšuje riziko regrese a ztěžuje vrácení změn v případě potřeby.
• Vynechání sloučení do develop — pokud se hotfix nesloučí do develop, oprava se ztratí při příštím vydání. Tým zjistí, že se stejná chyba objevila znovu, a bude ji muset znovu opravovat.
• Nesprávný tag verze — hotfix by měl obdržet inkrement záplaty (v2.3.0 → v2.3.1), nikoli minor (v2.4.0) nebo major (v3.0.0). Porušení sémantického verzování narušuje build systém a mate uživatele.
• Chybějící CI kontroly — i nouzový hotfix by měl projít automatickými testy. Vynechání CI zvyšuje riziko zavedení nové chyby. Doporučuje se mít samostatný pipeline pro hotfix větve se zrychlenými kontrolami.

Každá z těchto chyb vede ke zpoždění vydání záplaty nebo k výskytu nových problémů v produkci. Týmy by měly stanovit pravidla pro práci s hotfix v CONTRIBUTING.md a automatizovat je pomocí CI/CD kontrol.