git im Team: Workflows und Branching-Modelle

git im Team: Workflows und Branching-Modelle

https://bildung.social/@oerinformatik/

https://oer-informatik.de/git05-workflow

git, Workflow, Branching-Modell, Feature-Branch, Merge Request, Pull Request, Forking, Gitflow, Trunk-based Development, Continuous Integration, Code-Review

tl/dr; (ca. 16 min Lesezeit): git schreibt nicht vor, wie ein Team Branches nutzt. Deshalb braucht jedes Team Regeln: Welche Branches leben lange, wie kommen Änderungen hinein, wer prüft sie, und wie entsteht ein Release? Dieser Artikel stellt die verbreiteten Workflows vor, vom zentralen Workflow über Feature-Branches mit Merge Requests und Forks bis zu Gitflow und Trunk-based Development, und hilft bei der Auswahl [AI-Assisted]. (Zuletzt geändert am 12.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über die Versionsverwaltung git: Erste Schritte und lokale Commits / git im Team und Remote nutzen / Versionieren mit Branches / Readme.md-Dateien erstellen / Workflows im Team / Übungsaufgaben

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Mit Branches, Merge und Rebase, push und pull hast Du in den vorigen Teilen alle Werkzeuge kennengelernt. git lässt Dir dabei völlig freie Hand: Jede*r darf jederzeit Branches anlegen, auf jeden Branch pushen und beliebig zusammenführen. Für eine Person ist das praktisch, für ein Team ist es ein Rezept für Chaos. Stell Dir das Projektteam vor, das die Mitfahr-App „Mitfahrlabor“ für das DBH-Berufskolleg entwickelt: Mehrere Auszubildende arbeiten gleichzeitig an Anmeldung, Fahrtangeboten und Flurmonitoren, und die Schule möchte jederzeit eine funktionierende Version im Einsatz haben. Ohne Absprachen überschreiben sich Änderungen, niemand weiß, welcher Stand getestet ist, und ein dringender Fehler lässt sich nicht beheben, ohne halbfertige Funktionen mit auszuliefern.

Ein Workflow (auch Branching-Modell oder Branching-Strategie) ist die Vereinbarung, wie ein Team git nutzt. Die Grafik zeigt die fünf Modelle dieses Artikels im Überblick, jeweils als kleinen Commit-Graphen.

Was ein Workflow festlegen muss

Ganz gleich, welches Modell ein Team wählt, es beantwortet immer dieselben Fragen:

• Langlebige Branches: Welche Branches gibt es dauerhaft (z. B. nur main oder zusätzlich develop), und welcher Stand liegt jeweils dort?

• Integration: Wie gelangen Änderungen in diese Branches? Direkt per push oder über einen Merge Request mit Prüfung?

• Qualitätssicherung: Wer liest den Code gegen (Code-Review), und welche automatischen Tests müssen grün sein, bevor zusammengeführt wird?

• Release: Wie entsteht eine auslieferbare Version, und wie wird sie markiert (meist mit einem Tag nach Semantic Versioning, z. B. v1.4.0)?

• Fehlerbehebung: Wie kommt eine dringende Korrektur in die laufende Version, ohne unfertige Funktionen mitzunehmen?

• Konventionen: Wie heißen Branches (feature/fahrt-anbieten, fix/login-timeout), und wie sind Commit-Nachrichten aufgebaut (siehe Erste Schritte)?

Die Antworten hängen davon ab, wie groß das Team ist, wie oft ausgeliefert wird und ob mehrere Versionen gleichzeitig gepflegt werden müssen.

Zentralisierter Workflow: alle auf main

Der einfachste Workflow kommt mit einem einzigen Branch aus. Alle klonen das Remote-Repository, committen lokal auf main und laden ihre Commits mit push hoch. Hat jemand anderes inzwischen etwas hochgeladen, wird der Push abgewiesen; dann holt man die fremden Commits, setzt die eigenen per Rebase darauf und versucht es erneut:

$ git switch main
$ git commit -am "feat: show free seats on ride offer"
$ git pull --rebase       # fremde Commits holen, eigene darauf aufsetzen
$ git push

Wer von einer zentralen Versionsverwaltung wie Subversion kommt, findet sich sofort zurecht. Für ein bis zwei Personen oder ein kleines Schulprojekt reicht das völlig aus. Mit wachsendem Team zeigen sich aber die Grenzen: Halbfertiges landet direkt auf main, es gibt keine Stelle, an der jemand die Änderungen prüft, und Konflikte fallen erst beim pull auf.

Feature-Branch-Workflow mit Merge Requests

Im Feature-Branch-Workflow bleibt main der einzige langlebige Branch, aber niemand committet mehr direkt darauf. Jede Änderung, ob neue Funktion oder Fehlerkorrektur, entsteht in einem eigenen Branch, der von main abzweigt. Ist sie fertig, stellt die Entwicklerin bzw. der Entwickler im Webinterface einen Merge Request (GitLab) bzw. Pull Request (GitHub, Bitbucket) für die Rückführung nach main. Dort sehen andere die Änderungen, kommentieren einzelne Zeilen und geben sie frei; eine Pipeline prüft parallel, ob alle Tests durchlaufen.

Ein Durchlauf für die neue Funktion „Fahrt anbieten“ sieht so aus:

$ git switch main
$ git pull                                   # aktuellen Stand holen
$ git switch -c feature/fahrt-anbieten       # eigenen Branch anlegen
$ git commit -am "feat(ride): add form to offer a ride"
$ git push -u origin feature/fahrt-anbieten  # Branch hochladen
# Merge Request im Webinterface anlegen, Review abwarten, Hinweise einarbeiten:
$ git commit -am "fix(ride): validate departure time"
$ git push
# nach der Freigabe wird im Webinterface gemergt, danach aufräumen:
$ git switch main
$ git pull
$ git branch -d feature/fahrt-anbieten

Damit niemand die Regeln versehentlich umgeht, wird main in GitHub und GitLab als geschützter Branch (protected branch) eingestellt: Direkte Pushes sind verboten, gemergt werden darf nur über einen Merge Request mit mindestens einer Freigabe und erfolgreicher Pipeline. Beim Mergen lässt sich wählen, ob ein Merge-Commit entsteht, ob die Commits des Branches per Rebase angehängt oder zu einem einzigen Commit zusammengefasst werden (squash).

Diese schlanke Form ist auch als GitHub Flow bekannt: main ist immer auslieferbar, alles andere passiert in kurzen Feature-Branches. Für die meisten Teams, die eine Web-Anwendung oder App laufend weiterentwickeln, ist das ein guter Ausgangspunkt.

Forking-Workflow: mitarbeiten ohne Schreibrechte

Bei Open-Source-Projekten können nicht alle Beteiligten Schreibrechte für das Haupt-Repository bekommen. Im Forking-Workflow legt deshalb jede*r Mitwirkende im Webinterface einen Fork an, eine serverseitige Kopie des Repositorys im eigenen Konto. Gearbeitet wird in Feature-Branches im eigenen Fork; zurück ins Original gelangen die Änderungen nur über einen Pull Request, den die Verantwortlichen des Projekts prüfen und annehmen.

Lokal gibt es damit zwei Remotes: origin (der eigene Fork, auf den Du pushen darfst) und meist upstream (das Original, aus dem Du nur liest):

$ git clone https://gitlab.example.org/martin/mitfahrlabor.git          # eigener Fork
$ git remote add upstream https://gitlab.example.org/dbh/mitfahrlabor.git
$ git fetch upstream                                            # Original aktualisieren
$ git switch -c fix/typo-impressum upstream/main
$ git commit -am "docs: fix typo in imprint"
$ git push -u origin fix/typo-impressum                         # in den eigenen Fork
# Pull Request vom Fork in das Original anlegen

Der Forking-Workflow ist der Standard in der Open-Source-Welt. Innerhalb einer Firma oder eines Schulprojekts, in dem alle demselben Team angehören, genügt meist der Feature-Branch-Workflow.

Gitflow: feste Rollen für viele Branches

Gitflow wurde 2010 von Vincent Driessen beschrieben und war lange das bekannteste Branching-Modell. Es verteilt die Arbeit auf zwei langlebige und drei Arten kurzlebiger Branches:

• main enthält nur ausgelieferte Versionen; jeder Commit dort ist ein Release und bekommt einen Tag.

• develop sammelt die fertigen Funktionen für das nächste Release.

• feature/… zweigen von develop ab und werden dorthin zurückgeführt.

• release/… zweigen von develop ab, wenn ein Release vorbereitet wird. Dort werden nur noch Fehler behoben und Versionsnummern angepasst; danach wird der Branch in main (mit Tag) und zurück in develop gemergt.

• hotfix/… zweigen für dringende Korrekturen direkt von main ab und werden ebenfalls in main und develop gemergt.

Ein Release-Zyklus in Befehlen, hier ohne Merge Requests und mit erzwungenen Merge-Commits (--no-ff), damit jede Zusammenführung im Graphen sichtbar bleibt:

$ git switch -c release/1.2.0 develop
$ git commit -am "chore: bump version to 1.2.0"
$ git switch main
$ git merge --no-ff release/1.2.0
$ git tag -a v1.2.0 -m "Release 1.2.0"
$ git switch develop
$ git merge --no-ff release/1.2.0
$ git branch -d release/1.2.0

Gitflow passt gut zu Software, die in klar abgegrenzten Versionen ausgeliefert wird und von der mehrere Versionen parallel gepflegt werden müssen, etwa installierbare Programme oder Firmware für Geräte. Für Web-Anwendungen, die laufend aktualisiert werden, ist es dagegen schwerfällig: Änderungen wandern über mehrere Branches, langlebige Branches laufen auseinander, und große Merges kurz vor dem Release erzeugen Konflikte. Driessen selbst hat 2020 in einer Anmerkung zu seinem Artikel empfohlen, für kontinuierlich ausgelieferte Software einen einfacheren Workflow wie GitHub Flow zu wählen.

Trunk-based Development: oft und klein integrieren

Trunk-based Development treibt die Idee des Feature-Branch-Workflows auf die Spitze. Es gibt einen Hauptbranch (den trunk, in git meist main), in den alle mindestens einmal am Tag integrieren. Entweder committen erfahrene Teams direkt auf main, oder sie nutzen sehr kurzlebige Branches, die nach wenigen Stunden bis höchstens ein, zwei Tagen per Merge Request zurückgeführt werden. Lange Feature-Branches sind ausdrücklich unerwünscht.

Damit das funktioniert, braucht es drei Zutaten:

• Kleine Schritte: Jede Änderung ist so klein, dass sie schnell geprüft und integriert werden kann. Konflikte bleiben dadurch klein.

• Continuous Integration: Eine Pipeline baut und testet jeden Stand von main automatisch. Schlägt sie fehl, hat die Reparatur Vorrang vor allem anderen.

• Feature-Flags: Funktionen, die über mehrere Tage entstehen, werden trotzdem laufend integriert, bleiben aber über einen Schalter in der Konfiguration ausgeblendet, bis sie fertig sind. Unfertiger Code ist also im Trunk, aber nicht aktiv.

Ausgeliefert wird entweder direkt aus main (bei Continuous Deployment nach jedem erfolgreichen Durchlauf) oder aus einem kurzen Release-Branch, der nur noch Korrekturen aufnimmt. Trunk-based Development gilt heute als Standard für Teams mit häufigen Auslieferungen. Es verlangt aber Disziplin und eine gute Testabdeckung; ohne automatische Tests ist ein ständig integrierter main schnell kaputt.

Welcher Workflow passt zu welchem Projekt?

Die Tabelle stellt die Modelle gegenüber. In der Praxis mischen viele Teams sie: Ein Feature-Branch-Workflow mit sehr kurzen Branches ist fast schon Trunk-based Development, und auch Gitflow-Teams nutzen Merge Requests.

Für das Mitfahrlabor-Team liegt ein Feature-Branch-Workflow mit geschütztem main, Merge Requests und kurzen Branches nahe: Die App wird laufend aktualisiert, es gibt nur eine Version im Einsatz, und das Review durch eine zweite Person hilft Auszubildenden, voneinander zu lernen. Mit wachsender Testabdeckung kann das Team die Branches immer kürzer halten und sich so Schritt für Schritt Richtung Trunk-based Development bewegen.

Fazit

Einen richtigen Workflow für alle gibt es nicht. Entscheidend ist, dass das Team ihn bewusst wählt, schriftlich festhält (z. B. in der CONTRIBUTING.md, siehe Readme.md-Dateien erstellen) und mit den Einstellungen des git-Dienstes absichert. Als Faustregel gilt: so wenige langlebige Branches wie möglich, Änderungen klein halten und oft integrieren, und vor jedem Zusammenführen prüfen lassen, ob Tests und Review grünes Licht geben.

Teile dieses Tutorials

• Ein git-Repository anlegen und lokal commiten

• Git Remote nutzen

• Versionieren mit Branches

• Übungsaufgaben zu git

• Readme.md Dateien für git-Repositorys erstellen

• Workflows im Team: zentral, Feature-Branches, Gitflow, Trunk-based

Leitfragen

1. Welche Fragen muss ein Team-Workflow für git beantworten? Antwort

Welche Branches dauerhaft existieren, wie Änderungen hineingelangen, wer sie prüft und welche Tests laufen, wie Releases entstehen und markiert werden, wie dringende Korrekturen ausgeliefert werden und welche Namens- und Commit-Konventionen gelten. siehe Abschnitt „Was ein Workflow festlegen muss“

2. Wie läuft ein Merge Request im Feature-Branch-Workflow ab? Antwort

Du zweigst von main einen eigenen Branch ab, committest dort und lädst ihn mit git push -u origin <branch> hoch. Im Webinterface stellst Du einen Merge Request nach main; andere prüfen den Code, die Pipeline testet ihn, und nach der Freigabe wird gemergt und der Branch gelöscht. siehe Abschnitt „Feature-Branch-Workflow mit Merge Requests“

3. Was unterscheidet den Forking-Workflow vom Feature-Branch-Workflow? Antwort

Im Forking-Workflow hast Du keine Schreibrechte für das Original. Du arbeitest in einer eigenen serverseitigen Kopie (Fork) und schlägst Änderungen per Pull Request vor; lokal gibt es dafür meist die Remotes origin (Fork) und upstream (Original). siehe Abschnitt „Forking-Workflow“

4. Welche Branches gibt es in Gitflow, und wofür sind sie da? Antwort

main enthält nur Releases mit Tags, develop sammelt fertige Funktionen, feature/… entwickeln einzelne Funktionen ausgehend von develop, release/… bereiten ein Release vor, und hotfix/… beheben dringende Fehler ausgehend von main. siehe Abschnitt „Gitflow“

5. Warum setzt Trunk-based Development auf Feature-Flags und automatische Tests? Antwort

Weil alle mindestens täglich in main integrieren, muss dieser Stand jederzeit funktionieren. Automatische Tests erkennen Fehler sofort, und Feature-Flags erlauben es, unfertige Funktionen schon zu integrieren, sie aber noch ausgeschaltet zu lassen. siehe Abschnitt „Trunk-based Development“

6. Für welche Projekte eignet sich Gitflow, für welche eher nicht? Antwort

Gitflow passt zu Software mit klar abgegrenzten Versionen, von denen mehrere parallel gepflegt werden, z. B. installierbare Programme oder Firmware. Für laufend ausgelieferte Web-Anwendungen ist es zu schwerfällig; dort sind Feature-Branch-Workflow oder Trunk-based Development besser geeignet. siehe Abschnitt „Welcher Workflow passt zu welchem Projekt?“

Links und weitere Informationen

• Überblick mit Grafiken: der Vergleich der Workflows bei Atlassian, mit Unterseiten zum Feature-Branch-Workflow, zum Forking-Workflow und zu Gitflow

• als Originalquelle zu Gitflow: Vincent Driessen: A successful Git branching model (englisch, mit der Anmerkung von 2020)

• zum Vertiefen: die Seite trunkbaseddevelopment.com (englisch) und das Plädoyer von Trisha Gee Why I prefer trunk-based development (englisch)

• für die Einstellungen: die Dokumentation zu geschützten Branches in GitLab und zu Pull Requests in GitHub

• als Nachschlagewerk: René Preißel / Bjørn Stachmann: Git (dPunkt Verlag, ISBN Print: 978-3-86490-649-7), mit ausführlichen Kapiteln zu Workflows

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “git im Team: Workflows und Branching-Modelle” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/git05-workflow veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/devoptools/git. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 12.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]