Hotfix Branch: Was es ist, wie man es in der mobilen Entwicklung erstellt und anwendet

Was ist ein Hotfix Branch?

Hotfix Branch ist ein temporärer Branch in Git, der zur schnellen Behebung kritischer Mängel in einer aktiven Produktionsumgebung erstellt wird. Im Gegensatz zu Feature-Branches, die von develop abzweigen und mehrere Tage oder Wochen bestehen, wird ein Hotfix von main/master erstellt und existiert nur so lange, wie für die Fehlerbehebung nötig.

Das Hauptziel eines Hotfix ist es, die Zeit zu minimieren zwischen der Entdeckung eines kritischen Fehlers und seiner Behebung in der Produktion. Das Team wartet nicht auf das Ende des aktuellen Sprints oder Release-Zyklus, sondern veröffentlicht sofort einen Patch. Dies ist besonders wichtig für mobile Anwendungen, wo ein kritischer Fehler Benutzer blockieren und zur Abwanderung führen kann.

Laut Google Play Console beträgt die durchschnittliche Überprüfungszeit für Updates in Google Play 2 bis 24 Stunden. Für den App Store kann die Express-Überprüfung 1 bis 4 Stunden dauern. Hotfix-Branches ermöglichen es, die Behebung vorzubereiten, bevor die Moderation abgeschlossen ist, und sie sofort nach der Genehmigung zu veröffentlichen.

Wie ein Hotfix funktioniert

Der Hotfix-Prozess besteht aus drei Schritten: Branch von main erstellen, Behebung durchführen und zurück in main und develop mergen. Der Hauptunterschied zu einer normalen Behebung ist, dass ein Hotfix immer in beide Branches gemergt wird, damit die Behebung im nächsten Release nicht verloren geht.

Das Team sollte in einen Hotfix keine neue Funktionalität oder Refactoring einführen. Nur eine gezielte Behebung, die minimal notwendig ist, um das kritische Problem zu lösen. Jede Abweichung von dieser Regel erhöht das Risiko von Regressionen und verzögert die Patch-Veröffentlichung.

Wann ein Hotfix nötig ist

Ein Hotfix ist in drei Szenarien notwendig: Ein kritischer Fehler blockiert Benutzer (Absturz, Datenverlust), eine Sicherheitslücke erfordert sofortige Schließung, oder die kritische Geschäftslogik ist defekt (Zahlungen, Authentifizierung). Wenn der Fehler nicht kritisch ist, kann er im normalen Release-Zyklus über develop behoben werden.

Für mobile Anwendungen kann ein Hotfix auch Serverseitige Änderungen umfassen, wenn die Architektur das ferngesteuerte Umschalten von Funktionen (Feature Flags) ermöglicht. In diesem Fall kann der Hotfix-Branch minimal sein oder gar nicht benötigt werden, wenn die Behebung serverseitig erfolgen kann.

Branching-Modelle und der Platz des Hotfix

Nicht alle Branching-Modelle unterstützen Hotfix-Branches. Traditionelles Git Flow enthält Hotfix als vollwertigen Branch-Typ, während modernere Ansätze (GitHub Flow, Trunk-based) Notfallbehebungen anders handhaben.

Git Flow und Hotfix

Git Flow ist das einzige Modell, bei dem Hotfix ein integrierter Branch-Typ neben Feature und Release ist. In Git Flow wird ein Hotfix von main erstellt und nach Abschluss sowohl in main (mit einem Versions-Tag) als auch in develop gemergt. Dies stellt sicher, dass die Behebung im nächsten Release nicht verloren geht.

GitHub Flow und Trunk-based

GitHub Flow verwendet keinen separaten Branch-Typ für Hotfix. Stattdessen erstellt der Entwickler einen normalen Feature-Branch von main, führt die Behebung durch und öffnet einen Pull Request. Nach Review und CI-Prüfungen wird der Branch in main gemergt und sofort deployed. Der Vorteil ist Einfachheit, der Nachteil das Fehlen eines dedizierten Kanals für dringende Behebungen.

Trunk-based Entwicklung handhabt Hotfix durch direkte Commits in main (für kritische Fälle) mit obligatorischem Post-Review. Dieser Ansatz erfordert hohe Teamdisziplin und zuverlässige automatisierte Tests, da Änderungen sofort in Produktion gehen.

Wie erstelle ich einen Hotfix Branch?

Einen Hotfix erstellen beginnt mit dem Wechsel zum Hauptbranch und dem Erstellen eines neuen Branches mit dem Präfix hotfix/. Betrachten wir den schrittweisen Prozess am Beispiel der Behebung eines kritischen Fehlers in einer mobilen Anwendung.

Branch von main erstellen

Erster Schritt — zu main wechseln und sicherstellen, dass der Branch aktuell ist. Dann einen Hotfix-Branch mit einem klaren Namen erstellen, der die Art der Behebung widerspiegelt.

# Zu main wechseln und die neuesten Änderungen abrufen
git checkout main
git pull origin main

# Einen Hotfix-Branch erstellen
git checkout -b hotfix/crash-on-login

Nach dem Erstellen des Branches kann die Behebung durchgeführt werden. Wichtig: Ein Hotfix sollte eine minimale Anzahl von Änderungen enthalten. Code nicht refaktorisieren oder neue Funktionen hinzufügen — nur die gezielte Behebung, die das Problem löst.

Behebung committen

Der Commit in einem Hotfix sollte eine informative Nachricht haben, die das Problem und seine Lösung klar beschreibt. Format: Typ(Bereich): Kurzbeschreibung + Link zur Aufgabe im Tracker.

# Geänderte Dateien hinzufügen
git add src/ui/login/LoginActivity.kt

# Einen Commit mit Beschreibung erstellen
git commit -m "fix(login): handle null intent on activity resume

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

Die Commit-Nachricht sollte eine Problembeschreibung und einen Link zur Aufgabe enthalten. Dies vereinfacht die Suche im Verlauf und hilft Kollegen zu verstehen, was behoben wurde und warum. Für mobile Projekte ist es üblich, auch die App-Version anzugeben, in der der Fehler gefunden wurde.

Merge in main und develop

Der letzte Schritt ist, den Hotfix zurück in main (mit einem neuen Patch-Versions-Tag) und in develop zu mergen (damit die Behebung im nächsten Release erhalten bleibt). Zuerst in main mit Tag mergen, dann in develop mergen.

# In main mergen und einen Tag erstellen
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# In develop mergen
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Änderungen auf den Server pushen
git push origin main --tags
git push origin develop

Das --no-ff-Flag stellt sicher, dass ein Merge-Commit erstellt wird, selbst wenn der Hotfix per Fast-Forward hätte angewendet werden können. Dies bewahrt die Information, dass eine Notfallbehebung durchgeführt wurde, und vereinfacht die zukünftige Verlaufsanalyse.

Unterschied zwischen Hotfix, Feature und Release

Ein Hotfix unterscheidet sich grundlegend von Feature- und Release-Branches hinsichtlich Zweck, Lebensdauer und Merge-Regeln. Das Verständnis dieser Unterschiede ist entscheidend für die richtige Organisation von Git-Prozessen im Team.

Ein Feature-Branch ist für neue Funktionalität gedacht. Er lebt von mehreren Tagen bis mehreren Wochen, wird von develop erstellt und zurück in develop gemergt. Ein Feature kann mehrere Commits enthalten, einschließlich experimenteller, die später durch Squash oder Rebase komprimiert werden.

Ein Release-Branch bereitet eine Veröffentlichung zum Deployment vor. Er wird von develop erstellt, darin werden während der Stabilisierung gefundene Fehler behoben, und er nimmt keine neue Funktionalität auf. Nach Abschluss wird der Release in main (mit Tag) und develop gemergt.

Ein Hotfix hingegen wird direkt mit main erstellt und gemergt, unter Umgehung von develop (obwohl er nach der Behebung auch mit develop synchronisiert wird). Er enthält eine minimale Anzahl von Änderungen und existiert für eine minimale Zeit. Während Feature- oder Release-Branches bis zum nächsten Zyklus verschoben werden können, kann ein Hotfix nicht verschoben werden.

Für die mobile Entwicklung ist diese Unterscheidung besonders wichtig: Der App Store und Google Play erlauben die Veröffentlichung von Patch-Versionen getrennt von Hauptveröffentlichungen. Der Hotfix-Branch stellt sicher, dass ein Patch-Release nicht mit unvollendeten Funktionen vermischt wird.

Typische Fehler bei der Arbeit mit Hotfix

Fehler bei der Arbeit mit Hotfix können die Vorteile der Notfallbehebung zunichtemachen. Betrachten wir die fünf häufigsten Probleme, die in Teams auftreten, die Git Flow verwenden.

• Hotfix von develop erstellen — wenn ein Hotfix von develop erstellt wird, können unvollendete Funktionen in den Patch gelangen. Ein Hotfix sollte nur von main erstellt werden, um sicherzustellen, dass nur stabiler Code in die Behebung einfließt.
• Mehrere Behebungen in einem Hotfix — jede Behebung sollte in einem eigenen Hotfix-Branch erfolgen. Das Mischen mehrerer Fehler in einem Branch erschwert das Code-Review, erhöht das Risiko von Regressionen und erschwert bei Bedarf den Rollback.
• Merge in develop überspringen — wenn ein Hotfix nicht in develop gemergt wird, geht die Behebung im nächsten Release verloren. Das Team stellt fest, dass derselbe Fehler erneut auftritt, und muss ihn erneut beheben.
• Falscher Versionstag — ein Hotfix sollte ein Patch-Inkrement erhalten (v2.3.0 → v2.3.1), kein Minor (v2.4.0) oder Major (v3.0.0). Die Verletzung semantischer Versionierung beschädigt das Build-System und verwirrt Benutzer.
• Fehlende CI-Prüfungen — selbst ein Notfall-Hotfix muss automatisierte Tests bestehen. Das Überspringen von CI erhöht das Risiko, einen neuen Fehler einzuführen. Es wird empfohlen, eine separate Pipeline für Hotfix-Branches mit beschleunigten Prüfungen zu haben.

Jeder dieser Fehler führt zu einer Verzögerung der Patch-Veröffentlichung oder zum Auftreten neuer Probleme in der Produktion. Teams sollten die Regeln für die Arbeit mit Hotfix in CONTRIBUTING.md dokumentieren und durch CI/CD-Prüfungen automatisieren.