Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

Git-Workflows einfach erklärt – so gelingt die Zusammenarbeit

Finde deinen richtigen Git-Workflow für die perfekte Zusammenarbeit. (Grafik: Shutterstock/Teguh Jati Prasetyo)

Du pushst deinen Code nur auf den Master-Branch? Das ist nicht sinnvoll und bei großen Projekten unproduktiv. Wie du deinen Git-Workflow perfektionierst und welcher für dich richtig ist, erfährst du in dieser Übersicht.

So gut wie kein Programmierprojekt kommt um Git herum. Spätestens bei mehreren Projektteilnehmern sollte aber ein Workflow festgelegt werden, bei dem ihr euch folgende Fragen stellt: Wann wird ein neuer Branch erstellt? Wie wird er benannt? Wann soll gepusht werden? Für all diese Fragen gibt es verschiedene Ansätze. Einige wollen wir euch heute vorstellen.

Einfacher Git-Workflow

Einfacher Git-Workflow mit nur einem Branch. (Grafik: t3n.de)
Einfacher Git-Workflow mit nur einem Branch. (Grafik: t3n.de)

Der einfache Workflow ist wohl der offensichtlichste. Ohne große Umstände werden Änderungen am Code nur auf dem Master-Branch gepusht. Mehr als diesen einen zentralen Branch gibt es nicht. Entwickler holen sich hier den aktuellen Commit, ändern den Code und pushen ihn für andere Developer zurück. Dieser „Workflow“ ist jedoch eher für kleine Ein-Mann-Projekte geeignet. Sobald das Projekt und das Team größer werden, verliert ihr sonst sehr schnell den Überblick und müsst euch mit viel mehr Merge-Konflikten herumschlagen als nötig.

Feature-Branches

Beim Feature-Branch-Workflow wird für jedes neue Feature vom Entwickler ein neuer Branch angelegt. (Grafik: t3n.de)
Beim Feature-Branch-Workflow wird für jedes neue Feature vom Entwickler ein neuer Branch angelegt. (Grafik: t3n.de)

Angenommen, das Projekt wird größer und ihr wollt eine bessere Struktur in eure Git-Verwaltung bringen, dann ist ein möglicher Schritt die Verwendung von Feature-Branches. Solch ein Feature sollte möglichst abgeschlossen und vom restlichen Projekt so unabhängig wie möglich sein. Ausgehend vom Master-Branch wird nun für jedes neue Feature ein eigener Branch erstellt. Ist das Feature abgeschlossen und lauffähig, wird der Branch mit dem Master-Branch gemerged.

Wie du in Git einen neuen Branch erstellst und alle weiteren wichtigen Befehle

Bei größeren Features kann es auch sinnvoll sein, die Branches hierarchisch aufzubauen: mit einer Art Unterfeatures. Solche Branches werden dann erst in den darüber liegenden Branch gemerged, bevor dieser mit dem Master-Branch zusammengeführt wird. Generell könnt ihr hier beliebig in die Tiefe gehen, solltet es aber der Übersicht wegen nicht übertreiben.

Developer-Branch

Erweiterung des einfachen Git-Workflows mit Developer-Branch. Veröffentlicht wird nur Code vom Master-Branch. (Grafik: t3n.de)
Erweiterung des einfachen Git-Workflows mit Developer-Branch. Veröffentlicht wird nur Code vom Master-Branch. (Grafik: t3n.de)

Statt für jedes Feature einen eigenen Branch zu erstellen, kann auch mit einem zweiten, langlebigen Developer-Branch gearbeitet werden. Auf dem wird solange programmiert, bis das Projekt für einen Release bereit ist. Dann wird der Developer-Branch in den Master gemerged. Auf dem Master-Branch befindet sich also nur Code, der jederzeit veröffentlicht werden kann.

Sobald mehrere Entwickler gleichzeitig an dem Projekt arbeiten wollen, treten jedoch ähnliche Probleme auf wie bei dem ganz einfachen Workflow. Für Ein-Mann-Projekte ist diese noch sehr einfache Strategie jedoch eine gute Lösung, da Release- von Entwicklungs-Code getrennt wird.

Wie du den Developer- mit dem Feature-Branch kombinierst, erfährst du auf der zweiten Seite.

Bitte beachte unsere Community-Richtlinien

7 Reaktionen
Shrek

Hi Andreas,

sorry für die letzte etwas vorschnell rausgehauene Antwort.

Das Video ist zwar lang, aber erklärt meiner Meinung nach sehr gut warum der einfache Workflow a.k.a trunk-based-development auch für große Projekte mit vielen Entwicklern geeignet ist. Und welche Strategien (Feature Toggles, Branch by Abstraction) sich für noch unfertigen Code anwenden lassen.
Er zeigt auch auf für welche Fälle Feature-Branches geeignet sind, z.B. Open-Source-Projekte mit vielen nicht vertrauenswürdigen Entwicklern. Da ja prinzipiell jeder Teilnehmen kann und der Code deshalb genauer und ggf. auch zeitlich versetzt geprüft werden muss.

Feature-Branches verletzten eigentlich auch immer die kontinuierliche Integration. Es sei denn sie sind sehr sehr kurzlebig. Nach meiner Erfahrung tendieren sie aber dazu den Code weniger häufig zu integrieren. Das lässt sich auch sehr gut im Buch Continous Delivery von Jez Humble nachvollziehen.

Zu guter letzt enden komplexe Workflows dann häufig im sogennaten Ci-Theatre . Siehe Thoughtworks Tech Radar. Stichwort Ci-Theatre.

Schöne Grüße
Shrek

Antworten
Andreas Domin

Hi Shrek,

das klingt alles sehr plausibel, was du sagst. Gerade für Open-Source-Projekte sind Feature-Branches wohl echt sinnvoll.
Deine Kritik an Feature-Branches ist wohl auch berechtigt und ein wichtiger Aspekt.

Danke für den Kommentar.

Viele Grüße
Andreas

Antworten
Peter

Andreas Domin,

finde ich auch was ist daran fahrlässig?

LG.

Antworten
Werbetechnik-Dyanmic

Hallo Andreas Domin,

wir sehen das genau so wie du. Warum soll es fahrlässig sein?

MfG.

Antworten
Shrek

Der Artikel verleitet meiner Meinung nach sehr fahrlässing die Einführung komplexer Git-Workflows, die häufig total überflüssing sind.

Siehe auch hier dieses sehr gute Video von Sam Newman zu genau dem Thema.

https://www.youtube.com/watch?v=lqRQYEHAtpk

Antworten
Andreas Domin

Hallo Shrek,

was genau ist denn deiner Meinung nach fahrlässig?
Im Artikel steht explizit drin, dass bei kleinen Ein-Mann-Projekten die einfacheren Workflows verwendet werden sollten. Bei größeren Projekten sind die komplexeren Workflows alles andere als überflüssig.

Ohne das verlinkte Video vollständig gesehen zu haben (habe an einigen Stellen kurz reingeschaut) wird das Thema sehr komplex eingeführt (zeigt schon die Länge des Videos), was alles andere als einfach ist. Genau das soll der Artikel eben vermitteln: einen einfachen Einstieg.

Falls ich was falsch verstanden habe, freue ich mich über erneute Rückmeldung.

Viele Grüße aus Hannover,
Andreas

Antworten
Shrek

Hi,

da habe ich mich etwas vorschnell hinreißen lassen mit meiner Wortwahl. Sorry! Das Video ist zwar etwas länger erläutert meiner Meinung nach aber sehr gut, warum der einfache Workflow a.k.a trunk-based-development auch für größere Teams geignet ist und welche Methoden (Feature Toggles, Branch By Abstraction) sich für ein direktes pushen auf den Master eignen, falls das Feature noch nicht komplett ist.

Durch Feature-Branches verhindert man auch, außer bei sehr kurzlebigen Branches, die Kontinuierliche Integration.
https://www.amazon.de/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

Bei komplexen Git-Workflows landet man dann häufig beim sogennanten Ci-Theatre
https://www.thoughtworks.com/de/radar/techniques/ci-theatre

Deshalb finde ich das propagieren von, je größer das Team, desto komplexer der Workflow ungünstig.

Schöne Grüße
Shreki

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.