Anzeige
Anzeige
Ratgeber

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

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.

Von Andreas Domin
4 Min.
Artikel merken
Anzeige
Anzeige

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

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)

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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

Die Kombination: Developer- und Feature-Branches

Im erweiterten Feature-Workflow haben die Feature-Branches nur Kontakt mit dem neuen Developer-Branch. (Grafik: t3n.de)

Im erweiterten Feature-Workflow haben die Feature-Branches nur Kontakt mit dem neuen Developer-Branch. (Grafik: t3n.de)

Die Kombination der beiden zuletzt vorgestellten Workflows ist ziemlich einfach. Auch hier muss der Master-Branch jederzeit bereit sein, veröffentlicht zu werden. Auf ihm darf nur Code liegen, der fertige Features beinhaltet und auch getestet wurde. Feature-Branches kommen nicht mehr in Kontakt mit dem Master-Zweig, sondern lediglich mit dem Developer-Branch. Von hier aus werden neue Verzweigungen für Features erstellt, die am Ende zunächst in den Developer-Branch gemerged werden. Nun kann der Code auf dem Developer-Branch getestet werden. Erst wenn die Tests durchgelaufen sind und alle wichtigen Features für einen möglichen Release bereitstehen, darf der Code vom Developer-Branch auf den Hauptzweig gemerged werden.

Die Erweiterung der Erweiterung: Release-Branches

Im dieser Erweiterung kommt der Release-Branch hinzu, der die Fertigstellung einer fertigen Version vereinfacht. (Grafik: t3n.de)

Im dieser Erweiterung kommt der Release-Branch hinzu, der die Fertigstellung einer fertigen Version vereinfacht. (Grafik: t3n.de)

Vor allem für große Projekte, die immer wieder neue Releases planen müssen, kann diese Erweiterung sehr sinnvoll sein. Sobald genug Features fertiggestellt sind, die veröffentlicht werden sollen, wird ausgehend vom Developer-Branch ein neuer Release-Branch erstellt. Darauf werden nun keine neuen Funktionen mehr ergänzt. Er dient lediglich dazu, Bugs zu beseitigen und den Code zu optimieren. Ist die Release-Version bereit für die Veröffentlichung, wird der Branch in den Master-, aber auch  zurück in den Developer-Branch gemerged. Diese Strategie ermöglicht das Optimieren des Releases fernab des Developer-Branches, wodurch ein anderer Teil des Teams parallel an neuen Features für die nächste Release-Version arbeiten kann.

Anzeige
Anzeige

Eine weitere kleinere Erweiterung dieser Strategie fügt einen weiteren Branch-Typ hinzu. Der Hotfix-Branch erlaubt unabhängig vom Developer-Branch, schnell benötigte Bugfixes direkt vom Master-Branch aus zu lösen. Dadurch muss ein schnell benötigter Release nicht den langen Umweg über den Developer-Branch gehen und kommt auch nicht in Kontakt mit bereits neu entwickelten Features.

Welchen Git-Workflow solltest du jetzt nutzen?

Als Faustregel für die richtige Wahl solltest du dir folgendes merken: je komplexer dein Projekt, desto komplexer dein Workflow. Aber auch Ein-Mann-Projekte sollten entweder Developer-Branches oder Feature-Branches verwenden. Sobald mehr als ein Entwickler an einem Projekt arbeitet, sollte die Kombination beider Branch-Typen genutzt werden. Bei einem größeren Projekt sollte über den Einsatz des Release-Branches nachgedacht werden. Der einfache Workflow sollte nur bei kleinen „Nur zum Spaß“-Projekten genutzt werden, die nicht offiziell veröffentlicht werden sollen.

Egal für welchen Workflow du dich entscheidest – du solltest eine wichtige Konvention bei der Benennung der Branches einhalten. Beispielsweise in der Form eines Präfix: feature/my-branch oder release/version1.

Alle Git-Workflows in der Übersicht
Einfacher Git-Workflow mit nur einem Branch. (Grafik: t3n.de)

1 von 5

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Kommentare (7)

Community-Richtlinien

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

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

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

Werbetechnik-Dyanmic

Hallo Andreas Domin,

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

MfG.

Peter

Andreas Domin,

finde ich auch was ist daran fahrlässig?

LG.

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

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

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Kommentar abgeben

Melde dich an, um Kommentare schreiben und mit anderen Leser:innen und unseren Autor:innen diskutieren zu können.

Anmelden und kommentieren

Du hast noch keinen t3n-Account? Hier registrieren

Anzeige
Anzeige