Sowohl in großen, als auch in kleinen Projekten ist Struktur und ein funktionierender Workflow wichtig. Mit Git, einer Software zur Versionsverwaltung, gibt es verschiedene Ansätze, einen Workflow zu implementieren.
Neben master-only (bei dem nur auf einem Branch gearbeitet wird), gibt es weitere Strategien, die unter anderem die Fehleranfälligkeit auf dem master-Branch stark verringern.
Vielleicht hast du schonmal von den Begriffen “Gitflow” und “GitHub Flow” gehört oder verwendest sie selbst in deinem Projekt. Vielleicht aber auch nicht und ich kann dir hier noch das eine oder andere erklären
Git Flow
Sieht kompliziert aus? Ist es eigentlich nicht.
Im Grunde läuft es so ab: Alles was die Kunden sehen und erhalten ist auf dem master-Branch. Der aktuellste Code-Stand liegt auf develop-Branch, von dem aus neue Features entwickelt werden. Um ein neues Feature nun zu implementieren, wird ein weiterer Branch geöffnet, nämlich der feature-Branch. Dadurch wird gewährleistet, dass du und dein Team sich nicht gegenseitig stören. Sobald du fertig bist und das Feature getestet hast, kannst du deine Änderungen wieder zurück in den develop-Branch mergen und weitere Features nach dem gleichen Prinzip abarbeiten. Das Mergen (auch Zusammenführen) geschieht meistens durch einen Pull-Request, welcher mit einem Code-Review verbunden ist. Wenn alles an deinem Code in Ordnung war, gibt es grünes Licht und du kannst deinen Branch mergen.
So. Du bist fertig mit allen neuen Features. Was jetzt? Bestimmt hast du schon die einzelnen Features getestet und würdest dein Projekt jetzt am Liebsten deinen Kunden zur Verfügung stellen. Aber hast du auch getestet, ob alle Features miteinander harmonieren? Dafür ist der release-Branch zuständig. Auf dem testest du dein Projekt solange, bis es wirklich funktioniert. Achtung: Auch hier musst du wieder zurück auf den develop- und feature-Branch gehen, wenn Fehler gefunden werden oder dir doch noch ein neues Feature eingefallen ist.
Du hast alles getestet, alle Features sind implementiert und du willst dein Projekt endlich veröffentlichen. Du hast meine Erlaubnis und darfst deinen Code wieder zurück in den master mergen. Hurraaa, Feierabend!
Aber halt! Was ist das? Ein paar Minuten später erhältst du einen Bug-Report vom Kunden. Beginnt der ganze develop - feature - release - Kreis jetzt von Neuem? Nein, du kannst aufatmen: Dafür gibt es den hotfix-Branch. In dem werden Fehler behoben, nachdem sich der Code schon auf dem master-Branch befindet.
GitHub Flow
Wenn dich der Gitflow schon abgeschreckt hat und du nicht mehr weiterlesen möchtest, kann ich dich beruhigen: Github Flow ist ziemlich simpel und auch einfach erklärt.
Der Github Flow besteht vereinfacht gesagt nur aus zwei Branches. Dem master, auf dem wie beim Git Flow alles für den Kunden sichtbar ist, und dem feature-Branch.
Wenn du also ein neues Feature hinzufügen möchtest, erstellst du einen feature-Branch, arbeitest, commitest und testest darauf. Sobald du der Meinung bist du bist fertig oder du Hilfe benötigst, erstellst du einen Pull-Request an den master-Branch. Jetzt können sich andere Entwickler:innen deine Änderungen anschauen und dir Feedback geben.
Sobald alles fehlerfrei ist, hast du grünes Licht deinen Code wieder auf den master zu mergen.
Easy, stimmts?
Welche Branching Strategie ist die Beste für dein Projekt?
Schonmal vorab: Man kann nicht von der Strategie für ein Projekt sprechen. Jedes Projekt hat individuelle Besonderheiten und sollte auch so behandelt werden. Im Groben kann man aber Punkte nennen, die es dir vielleicht einfacher machen, dein Projekt einer passenden Strategie zuzuordnen.
Wie du wahrscheinlich schon gemerkt hast, ist der Git Flow ein recht langer Prozess. Das heißt für Projekte, die schnelle Releases besitzen, eignet sich GitHub Flow besser. Auch, was die Komplexität und schnelles Feedback angeht, punktet GitHub Flow.
Trotzdem ist der GitHub Flow gerade für größere Projekte zu wenig strukturiert und organisiert. Auch das Testen von mehreren Features im Zusammenspiel wird mit nur zwei Branches erschwert, wodurch der master mit höherer Wahrscheinlichkeit einen Fehler aufweist, als beim Git Flow.
