Git-Tutorial: Gitflow oder trunk-based, das Branching-Modell wählen

Git schreibt dir keine Organisation vor. Es gibt dir die Branches aus dem vorigen Kapitel, und du entscheidest, welche es gibt, wer sie anlegt und wann sie zusammengeführt werden. Diese Entscheidung nennt sich Branching-Modell, und zwei große Familien teilen sich das Feld: Gitflow und das trunk-based development. Dieses Kapitel stellt beide mit ihren echten Befehlen vor und erklärt, in welchem Kontext sich welches rechtfertigt.

Was aus Gitflow geworden ist

Gitflow wurde im Januar 2010 von Vincent Driessen in einem Artikel mit dem Titel A successful Git branching model beschrieben. Das Modell wurde massenhaft übernommen, bis es für eine ganze Entwicklergeneration zum Standardreflex wurde.

Am 5. März 2020 hat der Autor seinem eigenen Artikel eine Klarstellung vorangestellt. Sie lohnt die Lektüre, bevor du das Modell übernimmst: Einem Team, das kontinuierlich ausliefert, empfiehlt er ausdrücklich ein deutlich einfacheres Vorgehen im Stil von GitHub Flow, statt Gitflow mit dem Schuhlöffel hineinzuzwängen. Gitflow behalte dagegen seinen vollen Sinn für Software, die ausdrücklich versioniert wird oder von der mehrere Versionen gleichzeitig in Produktion gepflegt werden müssen.

Anders gesagt lautet die Frage nicht „ist Gitflow gut oder schlecht“, sondern „was liefere ich aus, und in welchem Takt“.

Trunk-based development

Das Prinzip passt in einen Satz: ein einziger langlebiger Branch, main, in den alle sehr häufig ihre Arbeit integrieren, über Branches mit sehr kurzer Lebensdauer.

Ein Branch lebt ein paar Stunden, einen Tag, selten länger. Er wird zusammengeführt, sobald die Arbeit in sich stimmig ist, auch wenn das Feature noch nicht fertig ist: Was die Nutzer noch nicht sehen sollen, verbirgst du hinter einem Feature-Schalter (feature flag), statt es auf einem Branch zurückzuhalten. main ist jederzeit deploybar, und die Continuous Integration ist es, die diese Eigenschaft garantiert.

# 1. von der neuesten Version von main ausgehen
git switch main
git pull --rebase

# 2. ein kurzer Branch, für genau eine Sache
git switch -c fix/calcul-prix

# 3. arbeiten, committen
git commit -am "Corrige le calcul du prix TTC"

# 4. veröffentlichen und eine Merge-Anfrage öffnen
git push -u origin fix/calcul-prix

# 5. nach Review und grüner CI in main mergen
git switch main
git merge --no-ff -m "Fusionne fix/calcul-prix" fix/calcul-prix
git branch -d fix/calcul-prix

Merge made by the 'ort' strategy.
 app.js | 1 +
 1 file changed, 1 insertion(+)
Deleted branch fix/calcul-prix (was 711bcbc).

*   d7cdba6 Fusionne fix/calcul-prix
|  
| * 711bcbc Corrige le calcul du prix TTC
|/  
* 5b45117 Ajoute app.js
* 38b7dc5 Ajoute la doc

Die Option --no-ff erzwingt einen Merge-Commit, selbst wenn ein einfaches Vorspulen gereicht hätte. Die Historie zeigt so explizit, dass ein Branch existierte und was er enthielt. Ohne -m öffnet Git den in Kapitel 1 konfigurierten Editor mit einer vorausgefüllten Nachricht. In der Praxis erledigen die Buttons Merge pull request von GitHub und Merge request von GitLab diese Arbeit für Sie.

Versionen werden mit Tags auf main markiert, ohne eigenen Branch:

git tag -a v1.0.0 -m "Première version publique"
git push origin v1.0.0

tag v1.0.0
Tagger: Damien Flandrin <dam@example.com>
Date:   Wed Sep 2 10:00:00 2026 +0000

Première version publique

Zieh dem leichtgewichtigen Tag immer den annotierten vor (-a mit einer Nachricht): Er hält Autor, Datum und einen Kommentar fest. Und vergiss die Nachricht nicht: ohne -m öffnet Git einen Editor, und in einer automatisierten Umgebung schlägt der Befehl fehl.

error: there was a problem with the editor 'false'
Please supply the message using either -m or -F option.

Gitflow

Gitflow ergänzt einen zweiten dauerhaften Branch und drei Familien temporärer Branches.

Beachte, dass der Produktions-Branch im Artikel von 2010 master hieß. Da die Hoster ihre Repositories heute auf main anlegen, wird hier dieser Name verwendet.

Gitflow von Hand

Dafür braucht es kein Werkzeug, das Modell ist nichts weiter als Branch-Disziplin.

# den Integrations-Branch anlegen, ein für alle Mal
git switch -c develop
git push -u origin develop

# ein Feature
git switch -c feature/livraison develop
git commit -am "Ajoute le calcul des frais de livraison"
git switch develop
git merge --no-ff -m "Fusionne feature/livraison" feature/livraison
git branch -d feature/livraison

# eine Version
git switch main
git merge --no-ff -m "Version 1.2.0" develop
git tag -a v1.2.0 -m "Version 1.2.0"

*   876ffba Version 1.2.0
|  
| * 269874d Fusionne feature/livraison
|/| 
| * afcc714 Ajoute la livraison
|/  
*   d7cdba6 Fusionne correctif/prix
|  
| * 711bcbc Corrige le calcul du prix
|/  
* 5b45117 Ajoute app.js

Gitflow mit dem Werkzeug git-flow

Für diese Abläufe gibt es einen Satz Befehle, der sie automatisiert. Das ursprüngliche Projekt wird nicht mehr gepflegt, gepflegt wird die AVH-Edition, in den meisten Paketmanagern unter dem Namen git-flow verfügbar.

git flow init -d       # -d übernimmt alle Standardnamen

Using default branch names.

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/root/a8/.git/hooks] 

Der Zyklus eines Features besteht danach aus zwei Befehlen:

git flow feature start facturation
# … du arbeitest und committest …
git flow feature finish facturation

Switched to branch 'develop'
Updating 5b45117..61c7618
Fast-forward
 facture.php | 1 +
 1 file changed, 1 insertion(+)
Deleted branch feature/facturation (was 61c7618).

Summary of actions:
- The feature branch 'feature/facturation' was merged into 'develop'
- Feature branch 'feature/facturation' has been locally deleted
- You are now on branch 'develop'

Der einer Version ebenfalls aus zweien. git flow release finish führt in main zusammen, setzt den Tag und überträgt anschließend alles nach develop:

git flow release start 1.1.0
# … Versionsnummer aktualisieren, letzte Korrekturen …
git flow release finish -m "Version 1.1.0" 1.1.0

*   1b1a31d Merge tag '1.1.0' into develop
|  
| *   48f5649 Merge branch 'release/1.1.0'
| |  
| | * eb133dd Prepare la version 1.1.0
| |/  
|/|   
* | 61c7618 Ajoute la facturation
|/  
* 5b45117 Ajoute app.js

Dieser Graph zeigt gut, was dem Modell vorgeworfen wird: drei Merge-Commits für eine Version, die nur ein einziges Feature enthielt.

Welches von beiden

Nimm trunk-based development, wenn du eine Webanwendung oder einen Dienst auslieferst, den du häufig deployst, wenn immer nur eine Version in Produktion ist, wenn dein Team klein ist und wenn du automatisierte Tests hast, die diesen Namen verdienen. Das trifft heute auf die große Mehrheit der Webprojekte zu, und es ist das Modell, das du standardmäßig wählen solltest.

Nimm Gitflow, wenn du nummerierte Versionen veröffentlichst, die deine Nutzer installieren, wenn du mehrere Versionen parallel pflegen musst, wenn eine formale Abnahmephase das Ende der Entwicklung von der Produktivsetzung trennt, oder wenn du unter regulatorischen Auflagen arbeitest, die Nachvollziehbarkeit pro Version verlangen. Bibliotheken, Desktop-Anwendungen, eingebettete Software, Versionen, die beim Kunden installiert werden: dort behält das Modell seine volle Berechtigung.

Wenn du allein anfängst, keins von beiden. Arbeite auf main, mach einen Branch, wenn du etwas Unsicheres ausprobierst, und setz einen Tag, wenn du zufrieden bist. Ein Modell übernimmst du an dem Tag, an dem ihr mehrere seid, und dann ist trunk-based am einfachsten einzuführen.

Ein letzter Rat: Übernimm ein Modell nicht, weil es als seriös gilt. Ein Gitflow, das ein Zweierteam mit täglichen Deployments anwendet, produziert leere release-Branches und überflüssige Merges. Das richtige Modell ist das, was zu deiner Art zu liefern passt.

Wie es weitergeht

Damit hast du die Grundlagen von Git. Drei Richtungen lohnen sich als Nächstes.

Zuerst die Continuous Integration, die unverzichtbare Ergänzung zum trunk-based development: deine Tests bei jedem Push automatisch laufen lassen. GitHub Actions und GitLab CI sind in diese Plattformen eingebaut und werden mit einer einfachen YAML-Datei in deinem Repository konfiguriert.

Dann die Merge-Anfragen, auf GitHub pull requests, auf GitLab merge requests. Sie organisieren das Code-Review im Team und sind in beiden hier vorgestellten Modellen das eigentliche Tor zu main.

Und schließlich die Notfallbefehle: git bisect, um per Halbierung den Commit zu finden, der einen Bug eingeschleppt hat, git cherry-pick, um einen bestimmten Commit aus einem anderen Branch zu holen, und git worktree, um mehrere Branches gleichzeitig in mehreren Ordnern zu öffnen.

Das vollständige Inhaltsverzeichnis bleibt über das Tutorial „Git lernen“ erreichbar, die übrigen Tutorials des Lernpfads über den Hub Webentwicklung.