Ratgeber

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

Seite 2 / 2

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.

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

Passende Artikel zum Thema Git:

Bitte beachte unsere 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

7 Kommentare
Shrek
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
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.

Antworten
Peter
Peter

Andreas Domin,

finde ich auch was ist daran fahrlässig?

LG.

Antworten
Shrek
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

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

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

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

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

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung