Release Branch in Git — was es ist, Zweck und Arbeitsablauf

Was ist ein Release Branch in Git

Release Branch ist ein temporärer Branch in Git Flow, der von develop erstellt wird, wenn das Team entscheidet, dass der aktuelle Funktionsumfang für eine Veröffentlichung bereit ist. Er existiert genau so lange, wie die finale Release-Vorbereitung dauert — von einigen Stunden bis zu mehreren Tagen.

Der Hauptzweck eines Release-Branches besteht darin, einen bestimmten Funktionsumfang für die Veröffentlichung einzufrieren, ohne die Entwicklung der nächsten Versionen zu stoppen. Während der Release-Branch für die Bereitstellung vorbereitet wird, können andere Entwickler weiterhin Feature-Branches in develop für die nächste Version mergen.

Im Release-Branch werden keine neuen Funktionen erstellt — nur Fehlerbehebungen, Aktualisierung der App-Version, Lokalisierung und Dokumentation. Nach Abschluss aller Arbeiten wird der Release-Branch in main (als Release markiert) und zurück in develop (damit die Fehlerbehebungen in zukünftige Versionen gelangen) gemerged.

Laut Atlassian, 2024 sind Release-Branches für Projekte mit regelmäßigen Release-Zyklen von entscheidender Bedeutung — sie gewährleisten Vorhersagbarkeit und Stabilität des Veröffentlichungsprozesses.

Lebenszyklus eines Release-Branches

Der Lebenszyklus eines Release-Branches von der Erstellung bis zur Löschung umfasst mehrere Phasen. Das Verständnis jeder Phase hilft dem Team, Aktionen zu synchronisieren und Fehler zu vermeiden.

1. Erstellung — vom letzten Commit von develop wird ein Branch mit dem Namen release/2.5.0 erstellt. develop nimmt weiterhin Feature-Branches für die nächste Version an.
2. Vorbereitung — im Release-Branch wird die App-Version in build.gradle, Info.plist und anderen Konfigurationsdateien aktualisiert.
3. Fehlerbehebung — kritische Fehler, die während der finalen Tests gefunden wurden, werden behoben. Nur Fehler — keine neuen Funktionen.
4. Finale Tests — das QA-Team führt Regressionstests auf dem Release-Branch durch. Neue Fehler werden zur Behebung in denselben Branch gesendet.
5. Merge in main — der Release-Branch wird mit dem Flag --no-ff in main gemerged. Ein Release-Tag wird erstellt: v2.5.0.
6. Merge in develop — der Release-Branch wird zurück in develop gemerged, damit die Fehlerbehebungen aus der Version in die aktuelle Entwicklung gelangen.
7. Löschung — der Release-Branch wird lokal und remote gelöscht, da seine Aufgabe erfüllt ist.

Schritt 6 — die Rückführung in develop — wird oft vergessen, ist aber von entscheidender Bedeutung. Ohne sie gelangen die im Release-Branch vorgenommenen Fehlerbehebungen nicht in develop, und dieselben Fehler könnten in der nächsten Version erneut auftreten.

Typische Dauer der Phasen eines Release-Branches

Die Lebensdauer eines Release-Branches hängt von der Komplexität der Version und der Codequalität in develop ab. Im Durchschnitt dauert die Vorbereitung für eine mittelgroße mobile Anwendung 2 bis 5 Werktage.

Was wird in einem Release-Branch gemacht

In einem Release-Branch wird ein streng begrenzter Satz von Aufgaben ausgeführt. Jede Abweichung von dieser Liste verstößt gegen das Git Flow-Modell und birgt Risiken für die Stabilität der Version.

Die Regel des Verbots neuer Funktionen ist die wichtigste in einem Release-Branch. Wenn eine Funktion es nicht rechtzeitig zur Version geschafft hat, wartet sie auf den nächsten Zyklus. Der Versuch, eine unvollständige Funktion in den Release-Branch zu drücken, ist die Hauptursache für Terminüberschreitungen und Produktionsfehler.

Versionsaktualisierung in einem mobilen Projekt

Im Release-Branch wird die Versionsnummer der Anwendung zwingend aktualisiert. Für Android sind dies die Felder versionCode und versionName in build.gradle; für iOS — CFBundleShortVersionString in Info.plist.

// build.gradle (App-Ebene) — Versionsaktualisierung im Release-Branch
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Für iOS — Aktualisierung von Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Unterschiede zwischen Release und Hotfix

Anfänger verwechseln oft Release- und Hotfix-Branches, obwohl ihre Zwecke grundlegend unterschiedlich sind. Die Wahl des falschen Branch-Typs kann eine kritische Korrektur verzögern oder den Release-Prozess stören.

• Quelle — Release wird von develop erstellt, Hotfix von main. Dies ist der Hauptunterschied, der alles andere bestimmt.
• Dringlichkeit — Release ist geplant: Das Team entscheidet, wann die Vorbereitung beginnt. Hotfix ist dringend: Ein Problem in der Produktion erfordert sofortige Behebung.
• Inhalt — Release kann mehrere Korrekturen und eine Versionsaktualisierung enthalten. Hotfix enthält nur eine kritische Korrektur.
• Merge — Release wird in main und develop gemerged. Hotfix wird ebenfalls in main und develop gemerged, jedoch prioritär.
• Lebensdauer — Release lebt 1 bis 7 Tage. Hotfix lebt 30 Minuten bis 1 Tag.

Wenn während der Release-Vorbereitung (im Release-Branch) ein Fehler gefunden wird — ist es eine normale Fehlerbehebung. Wenn ein Fehler in der Produktion (auf main) gefunden wird — ist es ein Hotfix, der von main erstellt wird, selbst wenn der Release-Branch bereits existiert.

Namenskonventionen für Release-Branches

Ein einheitlicher Namensstandard für Release-Branches vereinfacht die Navigation im Repository und ermöglicht CI/CD-Systemen, automatisch zu erkennen, dass ein Branch zum Release-Prozess gehört.

• release/X.Y.Z — Standard-Git-Flow-Format, wobei X.Y.Z die Release-Version ist. Beispiel: release/2.5.0.
• release/Name — alternatives Format mit einem Release-Codename. Beispiel: release/merlin.
• release/Datum — Format mit dem Release-Datum. Wird selten verwendet, da die Version wichtiger als das Datum ist. Beispiel: release/2024-12-01.

Das Format release/X.Y.Z wird bevorzugt, da es den Branch explizit mit der Versionsnummer verknüpft, die der Version zugewiesen wird. Dies vereinfacht die Suche und die automatische Verarbeitung durch CI/CD-Skripte.

Strategie für die Rückführung in develop

Die Rückführung (Merge Back) des Release-Branches in develop ist einer der wichtigsten und gleichzeitig am häufigsten übersehenen Vorgänge. Ohne sie bleiben alle im Release-Branch vorgenommenen Fehlerbehebungen nur in der Release-Version und gelangen nicht in den nächsten Release-Zyklus.

Der Rückführungsprozess wird durchgeführt, nachdem der Release-Branch bereits in main gemerged wurde. Zuerst wird release in develop gemerged, dann gelöscht. Dies stellt sicher, dass develop alle während der Release-Vorbereitung vorgenommenen Korrekturen enthält.

Nach der Rückführung können Konflikte auftreten — insbesondere wenn in develop bereits neue Feature-Branches aufgetaucht sind, die dieselben Dateien geändert haben. Der für die Version verantwortliche Entwickler löst diese Konflikte und pusht develop auf den Server.

Einige Teams verwenden Rebase anstelle von Merge für die Rückführung, um die Historie linear zu halten. Merge ist jedoch sicherer für develop, da es die Commit-Historie nicht umschreibt, die von anderen Entwicklern bereits verwendet werden könnte.

Beispielbefehle für die Arbeit mit Release

Betrachten wir den vollständigen Zyklus der Arbeit mit einem Release-Branch: von der Erstellung bis zur Löschung nach einer erfolgreichen Version einer mobilen Anwendung 2.5.0.

# 1. Release-Branch von develop erstellen
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Version und Fehlerbehebungen aktualisieren
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Fehler beheben (nur Bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Release-Branch auf Server pushen
git push origin release/2.5.0

# 5. Release in main mergen
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Rückführung in develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Release-Branch löschen
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Die Befehle 5 und 6 — die doppelte Zusammenführung — sind von entscheidender Bedeutung. Zuerst erhält main den Release-Code und den Tag, dann synchronisiert develop sich mit den Fehlerbehebungen aus release. Wenn Schritt 6 übersprungen wird, gelangen die Korrekturen aus der Version nicht in den nächsten Entwicklungszyklus.

Automatisierung des Release-Prozesses

Für mobile Projekte mit regelmäßigen Versionen kann der Prozess der Erstellung eines Release-Branches und der Aktualisierung der Version über CI/CD-Skripte automatisiert werden. GitHub Actions ermöglicht die Erstellung eines Workflows, der auf Knopfdruck einen Release-Branch mit automatischer Versionsaktualisierung erstellt.

Für mobile Projekte mit regelmäßigen Versionen kann der Prozess der Erstellung eines Release-Branches und der Aktualisierung der Version über CI/CD-Skripte automatisiert werden. GitHub Actions ermöglicht die Erstellung eines Workflows, der auf Knopfdruck einen Release-Branch mit automatischer Versionsaktualisierung erstellt.

# GitHub Actions — Automatisierung der Release-Branch-Erstellung
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}