Git Workflows
Allgemeines
Für Anfänger ist es eher hinderlich, wenn gerade Programmieren oder Webdesign in den ersten Schritten erlernt wird. Sobald das erste richtige eigene Projekt ansteht, ist die Versionierung ein schönes Hilfsmittel, um den Überblick zu behalten. Dabei ist die Versionierung nicht immer einfach umzusetzen und je nach Größe und Anforderung an das Softwareprodukt oder das Entwickler-Team unterschiedlich anwendbar.
Versionierung-Werkzeuge gibt es für Dokumente (z.B. Word und Excel-Dateien), für Videoschnitt, für Kinofilme, Softwareentwicklung (z.B. Erfassung der Quellcode-Veränderungen), … Diese Tools vereint alle, dass meist mit einer Datenbank gearbeitet wird oder zumindest irgendeiner Form von Protokollierung von Änderungen eingesetzt wird.
Was ist Git?
Git ist ein System zur verteilten Versionsverwaltung von Dateien. Dieses System wurde von Linus Torvalds vorgeschlagen und initiiert. Git soll die Versionierungskontrolle von großen und kleinen Projekten effizient und schnell ermöglichen. Mehr zu Git erfährst du auf der Website von Git oder auf Wikipedia (DE).
Workflows:
Es gibt eine Vielzahl an Workflows, welche sich nach Rechtevergaben und Struktur des Projektes richten können. Im Grunde kann jeder Entwickler*in einen eigenen Workflow erstellen und diesen nutzen. Beispielsweise liefert die Plattform GitHub.com mit GitHub-Actions die Möglichkeit, einen eigenen Workflow zu erstellen und in den eigenen Repositorys zu nutzen.
Die folgenden Workflows sind eine Auswahl der üblichsten Workflows für Git.
- Basic Workflow
- Feature Branch Workflow
- Git Flow
- Gitlab Flow
- Forking Flow
- Trunk-Based Development Flow
Streng vs. offenerer, lockerer Workflows:
Früher wurden strengere Entwicklungsmodelle eingesetzt (ab 2005, 2010, …). Bei diesen konnten nur bestimmte Personen mit den nötigen Rechten Änderungen am Master-Branch und seinem Code vornehmen. Dies sollte die Codequalität sichern und die Anzahl der Fehler beim mergen/ verschmelzen von Quellcode minimieren. Mittlerweile nutzen gut ausgebildete Teams mit den nötigen Fähigkeiten Trunk-basierte Prozesse. Alle Entwickler haben den gleichen Zugriff auf den Hauptcode und können somit schnelle Iterationen durchführen. Ebenfalls lassen sich Trunk-basierte Prozesse für die Versionierung von Software mit Git leichter in eine CI/CD implementieren.
Basic Workflow
Dieser umfasst nur ein einziges zentrales Repository. Der Workflow eignet sich besonders für 1-Personen-Projekte oder wenn mehrere Personen am Code arbeiten, dann wird das Repository geklont. Jeder Entwickler*in muss dann schauen, dass das lokale Repository auf dem eigenen PC immer aktuell ist. Änderungen und Erweiterungen des Codes werden dann final in das Master-Repo hochgeladen (Git: commit pushen), sodass es für die anderen Entwickler zugänglich ist. Für einfache Projekte eignet sich dieser Workflow hervorragend, aber sobald mehrere Leute an unterschiedlichen Funktionalitäten arbeiten wird das zu Konflikten und Problemen im Quellcode führen. Diese müssen dann aufwendig mit einem Cherry-Pick behoben werden. Dabei ist auch nicht klar, ob nicht weitere Fehler entstehen.
Basic Workflow Git nur mit Master Branch
Feature Branch Workflow
Arbeiten mehrere Entwickler*innen an einem Projekt gleichzeitig, aber an unterschiedlichen Funktionen, ist der Feature Branch Workflow gefragt. Ist das eine Feature fertiggestellt, kann dieses in den Master-Branch zurück verschmolzen werden. Das andere Feature kann weiterentwickelt werden, ohne dass das neue erste Feature das zweite beeinflusst. Bei längeren Entwicklungen sollte der Master auch in den Feature-Branch hereingezogen (pullen) werden, um eventuelle Codeänderungen der bereits fertigen Module der Software-Teile zu berücksichtigen, z.B. Bug-Fixing. Hier liegt auch die Schwäche dieser Vorgehensweise, da bei vielen Features und großen Teams es dann schnell zu einigen Cherry-Picks kommen kann. Die wiederum weitere Bugs oder Fehler hervorrufen können.
Feature Brach Workflow für mit Git
Git Flow
Der Git-Flow ist einer der ersten Flows, die sich wirklich durchgesetzt haben. Bei großen Projekten haben sich zwei gleichzeitige parallele Zweige, der Master- und der Development-Zweig, als zielführend herausgestellt. Dabei wird der Master nur für Releases der Software benutzt und der Dev-Branch nur für stabile Features und Bugfixing vor dem Release.
Es kann mitunter vorkommen, dass ein Hot-Fix für einen plötzlich auftretenden Bug durchgeführt werden muss. Dieser wird dann direkt in den Master und Dev-Zweig eingefügt. Tritt der Fehler aber nur im Dev-Branch auf, dann wird dieser dort gefixt und nur in den Dev-Branch gemerged. Ansonsten funktioniert der Git-Flow wie der Feature-Branch-Workflow.
Der Git-Flow war etwa ab 2010 Standard für viele Entwicklungen für verschiedene Softwares.
Gitlab Flow
Dieser Flow ist eine Erweiterung des Git Flows. Dieser wurde unter bestimmten Richtlinien und Best-Practices entsprechend erweitert und somit verbessert. Diese Richtlinien werden für ein Projekt durch das Team selbst gewählt und teilweise neu zusammengestellt oder aus alten Projekten übernommen.
Forking Flow
Ein komplettes Repository zu gabeln (forken) ist einfach und macht mit Sicherheit auch Spaß, wenn die eigenen Änderungen und Verbesserungen in den Master z.B. eines Open Source Projektes übernommen werden. Dabei werden alle Entscheidungen über pushen und mergen durch den Besitzer/ die Besitzerin des Repos entschieden. Die große Stärke dieses Flows liegt in der Freiheit, dass jeder Entwickler*in autonom an Features arbeiten kann und nach Fertigstellung eine Pull-Request einreichen.
Trunk-Bases Development Flow
Mithilfe des Trunk-Based-Workflows arbeiten alle Entwickler*innen eines Teams auf einem gemeinsamen Zweig. Dies ist meist der Master, aber dieser Workflow kann auch auf einen Dev-Branch gut angewendet werden. Vom diesem Dev-Branch werden dann die Releases zum Master gepullt und gemerged. Alle pushen immer nur auf diesen Haupt-Zweig. Alle pullen regelmäßig vom Hauptzeig und verschaffen sich einen Überblick über die Änderungen der anderen Team-Mitglieder*innen.
Eine Quellcodereview kann nur mithilfe des vollständigen Codes durchgeführt werden, da es keine größeren Codeaufteilungen durch z.B. mehrere Features gibt. Dabei hat auch niemand eine starke Kontrolle darüber, welche Bestandteile gemerged werden und welche nicht.
Diese Art der Entwicklung kann nur mit Teams durchgeführt werden, die sich strickt an einen Styleguide, Best-Practices halten und ein gewisses Maß an Erfahrung mitbringen.
Wichtig: Vertrauen wird vorausgesetzt. Die Verantwortlichen für ein Projekt müssen abwegen, ob das Vertrauen ausreichend ist. Sollte es Bedenken geben, ist dies wahrscheinlich nicht der passende Workflow und es sollte der Git-Workflow gewählt werden.