Zusammenarbeit meistern: Warum ein guter Git-Workflow den Erfolg des Projekts mitbestimmt

Eine Einführung in die Zusammenarbeit in der Softwareentwicklung mit Git sowie einen Vergleich verschiedener Git-Workflows.

Transcript

1. Zusammenarbeit meistern: Warum ein guter Git- Workflow den Erfolg des Projekts mitbestimmt. Florian Arens Barcamp VI
2. Einführung (Stack Overflow Developer Survey 2022, 71,379 Abstimmungen)
3. Einführung: Was ist Git? • verteilte Versionsverwaltung • wird hauptsächlich in der Softwareentwicklung eingesetzt • ermöglicht Zusammenarbeit zwischen Entwicklern • erkennt Änderungen in Dateien • erleichtert das Zusammenführen von Änderungen • vollständige Projekthistorie von Änderungen • Rollback zu älteren Versionen • ermöglicht einen besseren Code-Review-Prozess ➔ verbessert den gesamten Workflow der Softwareentwicklung
4. Die Vorteile von Git • “Branching” and “Merging” • schnell • verteilt • Datensicherheit • Staging Area • kostenlos und Open-Source
5. Bestandteile von Git • Repository • Branch • Commit • Merge und Pull-Request
6. GitHub und GitLab • cloudbasierte Hosting-Services für Git-Repositories • erleichtert die Verwendung von Git • benutzerfreundliche Oberfläche für die Verwaltung eines Repositories • wird aufgrund der Benutzerfreundlichkeit nicht nur in der Softwareentwicklung genutzt • jeder kann kostenlos ein öffentliches Git-Repository erstellen • besonders GitHub beliebt für Open-Source Projekte
7. Warum Git die Zusammenarbeit erleichtert • gleichzeitige Zusammenarbeit an einem Projekt • unabhängige Entwicklung von Funktionen (“Branching”) • Unterstützung bei der Zusammenführung von Code (“Merging”) • einfache Wiederherstellung von früheren Versionen • Nachvollziehbarkeit durch Projekthistorie • Integration für verschiedene Projektmanagement-Tools ➔ effiziente und effektive Softwareentwicklung im Team
8. Was ist ein Git-Workflow? • strukturierter Prozess für die Verwendung von Git • Definition wie Codeänderungen verwaltet und organisiert werden • Strategien für Branching und Merging • legt fest, wie Releases und Hotfixes gehandhabt werden • gewährleistet wartbare und stabile Codebasis • konsistente und vorhersehbare Entwicklung • kann an die Bedürfnisse des Projekts und Teams angepasst werden • Weiterentwicklung durch Veränderungen des Projekts und des Teams
9. Centralized Workflow • Änderungen werden direkt im Main-Branch gemacht • es werden keine anderen Branches erstellt • Konflikte müssen lokal gelöst werden, bevor Änderungen hochgeladen werden
10. Centralized Workflow: Ablauf • Entwickler klont Repository • lokales Repository wird kontinuierlich auf den neuesten Stand gebracht • es werden Änderungen im Hauptzweig durchgeführt • Änderungen werden zum serverseitigen Repository hochgeladen • sollten Konflikte entstehen, müssen diese zunächst lokal gelöst werden
11. Centralized Workflow: Wann einsetzen? Teams, die von SVN zu Git wechseln und Projekte mit einem ähnlichen Workflow entwickeln wollen Entwickler arbeitet alleine an einem Projekt es soll schnellstmöglich ein MVP erstellt werden Projekt befindet sich in der Anfangsphase
12. Centralized Workflow: Wann nicht einsetzen? Projektkomplexität ist hoch es arbeiten mehrere Entwickler an einem Projekt Projekt ist langlebig
13. Git-flow Workflow • wurde erstmalig 2010 von Vincent Driessen vorgestellt • Git-Branching Modell, das Feature-Branches und mehrere primäre Branches verwendet • es gibt mehrere und langlebige Branches • Entwicklungszweige haben strikte Zugriffsrechte • weist verschiedenen Branches spezifische Rollen zu
14. Git-flow: Ablauf • es gibt ein Haupt-Entwicklungszweig • Entwickler erstellt Feature-Branch • es wird ein Pull-Request erstellt, sobald das Feature fertig ist • im Pull-Requests wird über Änderungen diskutiert • Feature-Branch wird mit develop Branch zusammengeführt • für Releases wird zunächst ein separater Release-Branch erstellt
15. Ist Git-flow noch zeitgemäß? • wurde vor 10 Jahren, kurz nach Git selbst, entwickelt • Git-flow wurde sehr populär und wird in vielen Teams als Allheilmittel behandelt • Trend geht in Richtung Webanwendungen, die fortlaufend bereitgestellt werden (Continuous Integration / Continuous Delivery) • es müssen selten mehrere Versionen einer Software unterstützt werden • Git-flow wirkt sich negativ auf Entwicklungszeit aus • Erfinder selbst empfiehlt Git-flow nicht mehr für Webanwendungen und Projekte, die einen Fokus auf regelmäßiger Veröffentlichung haben
16. Git-flow: Wann trotzdem einsetzen? Open-Source Projekt • strikte Zugriffsberechtigungen werden benötigt • jede Zeile Code muss überprüft werden • Entwicklungszeit spielt oft keine Rolle Team mit vielen neuen Entwicklern • erfahrene Entwickler haben durch Pull-Requests mehr Kontrolle über den Code Produkt, in dem mehrere Versionen unterstützt werden müssen
17. Git-flow: Wann nicht einsetzen? Projekt steht noch am Anfang, MVP im Fokus Entwicklungszeit spielt eine große Rolle Team besteht aus erfahrenen Entwicklern Software soll kontinuierlich bereitgestellt werden (CI /CD)
18. GitHub Flow Workflow • schlanker, branchbasierter Workflow • Weiterentwicklung von Git-flow • es gibt einen Hauptzweig, der immer “deployable” ist (in der Regel main) • es wird nicht mehr zwischen Feature oder (Hot)-Fix Branches unterschieden
19. GitHub Flow Workflow: Ablauf • Entwickler erstellt Feature-Branch • Änderungen werden zum Feature-Branch hinzugefügt • es wird ein Pull-Request erstellt • Änderungen werden diskutiert und akzeptiert • Feature-Branch wird direkt in den main-Branch integriert • main-Branch wird kontinuierlich veröffentlicht
20. GitHub Flow Workflow: Vorteile • Komplexität wird reduziert • kürzere Feedbackschleifen • große Konflikte werden vermieden (“Merge Hell”) • es gibt eine aktuelle Version des Projekts • CI / CD wird vereinfacht bzw. ermöglicht
21. Trunk-based Workflow • Mischung aus Git-flow und GitHub Flow • kurzlebige Feature-Branches • es gibt einen Hauptzweig • alle Entwickler haben Zugriff auf Hauptzweig • Hauptzweig bzw. main Branch wird kontinuierlich veröffentlicht • Feature-Flags werden benötigt
22. Trunk-based Workflow: Ablauf • bei Bedarf werden kurzlebige Feature-Branches erstellt • kleine Pull-Requests werden erstellt und akzeptiert • Alternativ: Commits direkt in master
23. Trunk-based Workflow: Vorteile • kürzere Feedbackschleifen durch kleine Feature-Branches • ermöglicht CI / CD • häufigere Releases • mehr Verantwortung für Entwickler • es muss nicht jede Zeile Code überprüft werden • kürzere Entwicklungszeit • A/B Tests möglich durch Feature-Flags
24. Trunk-based Workflow: Wann einsetzen? Team besteht aus erfahrenen Entwicklern Teamgröße ist überschaubar Projektkomplexität ist nicht zu hoch Entwicklungszeit soll so gering wie möglich sein
25. Trunk-based Workflow: Wann nicht einsetzen? es gibt keine ausreichenden automatisierten Tests verschiedene Versionen eines Projekts sollen gepflegt werden Fokus liegt auf hoher Codequalität viele unerfahrene Entwickler sind beteiligt
26. Forking Workflow • jeder Entwickler besitzt ein eigenes serverseitiges Repository (fork) und eine lokale Kopie dieses Repositories • wird oft in Open-Source Projekten eingesetzt • Commits können integriert werden, ohne Schreibzugriff auf das offizielle Repository zu vergeben • baut oft auf Git-flow auf, d.h. es werden nur komplette Feature-Zweige in das offizielle Repository übernommen • flexible Möglichkeit für große, verteilte Teams (einschließlich nicht vertrauenswürdiger Dritter)
27. Forking Workflow: Ablauf • Entwickler erstellt eine Kopie (“fork”) des offiziellen Repositories • serverseitige Kopie wird auf das lokale System des Entwicklers geklont • ein neuer Feature-Branch wird lokal erstellt • Änderungen am Feature-Branch werden vorgenommen • Feature-Branch wird zur serverseitigen Kopie des Entwicklers verschoben • Entwickler erstellt einen Pull-Requests vom Feature-Branch zum offiziellen Repository • Änderungen werden genehmigt und zum offiziellen Repository hinzugefügt
28. Git-Workflow: Welche Faktoren berücksichtigen? • Teamgröße und Erfahrung des Teams einschätzen • Projektgröße und Komplexität berücksichtigen • Häufigkeit von Releases und Rolle von CI / CD bestimmen • Integration mit anderen Tools • Workflow dokumentieren und Richtlinien schreiben • Schulung und Unterstützung des Teams • Git-Workflow regelmäßig evaluieren • Effektivität des Workflows beobachten
29. Warum ist ein passender Git-Workflow so wichtig? • gewährleistet eine konsistente und organisierte Codeverwaltung • erleichtert die Zusammenarbeit zwischen Teammitgliedern • Verbesserung der Codequalität durch Reviews und Feedback • unterstützt ein einfaches Rollback und eine Wiederherstellung früherer Versionen • effiziente Zuweisung von Aufgaben • verbessert die Produktivität des gesamten Teams • erhöht die Wartbarkeit von Projekten • Entwicklungsprozess ist vorhersehbarer
30. Takeaways • Git-Workflows bieten Struktur und Organisation für die Codeverwaltung • Schlüsselfaktor für den Erfolg eines Projekts, da Git-Workflows eine effiziente und effektive Entwicklung fördern • Bewusstsein schaffen für verschiedene Git-Workflows • es gibt kein Allheilmittel • Git-Workflow dokumentieren und Entwickler schulen • Zusammenarbeit mit Git regelmäßig evaluieren und anpassen
31. Referenzen • https://www.atlassian.com/git/tutorials/comparing-workflows • https://www.atlassian.com/continuous-delivery/continuous- integration/trunk-based-development • https://docs.github.com/de/get-started/quickstart/github-flow • https://www.toptal.com/software/trunk-based-development-git-flow • https://about.gitlab.com/topics/version-control/what-is-git-workflow/ • https://git-scm.com/ • https://githubflow.github.io/