Kapitel ▾ 2. Auflage

5.1 Verteiltes Git - Verteilte Workflows

Nachdem Sie nun ein entferntes Git-Repository eingerichtet haben, das als Sammelpunkt für alle Entwickler zur gemeinsamen Nutzung ihres Codes dient, und Sie mit den grundlegenden Git-Befehlen in einem lokalen Workflow vertraut sind, werden Sie sich nun damit beschäftigen, wie Sie einige der verteilten Workflows nutzen können, die Git Ihnen bietet.

In diesem Kapitel lernen Sie, wie Sie in einer verteilten Umgebung mit Git als Mitwirkender und Integrator arbeiten. Das heißt, Sie lernen, wie Sie Code erfolgreich zu einem Projekt beitragen und es für Sie und den Projektverantwortlichen so einfach wie möglich machen, und auch, wie Sie ein Projekt erfolgreich mit einer Reihe von Mitwirkenden pflegen.

Verteilte Workflows

Im Gegensatz zu zentralisierten Versionskontrollsystemen (CVCSs) ermöglicht die verteilte Natur von Git eine viel flexiblere Zusammenarbeit der Entwickler an Projekten. In zentralisierten Systemen ist jeder Entwickler ein Knotenpunkt, der mehr oder weniger gleichberechtigt mit einer zentralen Anlaufstelle arbeitet. In Git ist jedoch jeder Entwickler potenziell sowohl ein Knotenpunkt als auch eine Anlaufstelle; das heißt, jeder Entwickler kann sowohl Code zu anderen Repositories beitragen als auch ein öffentliches Repository pflegen, auf dem andere ihre Arbeit basieren und zu dem sie beitragen können. Dies eröffnet eine riesige Bandbreite an Workflow-Möglichkeiten für Ihr Projekt und/oder Ihr Team, daher werden wir einige gängige Paradigmen abdecken, die diese Flexibilität nutzen. Wir werden die Stärken und möglichen Schwächen jedes Designs besprechen; Sie können eines auswählen oder Funktionen aus mehreren kombinieren.

Zentralisierter Workflow

In zentralisierten Systemen gibt es im Allgemeinen ein einziges Kooperationsmodell – den zentralisierten Workflow. Eine zentrale Anlaufstelle oder ein Repository kann Code akzeptieren, und jeder synchronisiert seine Arbeit damit. Eine Reihe von Entwicklern sind Knotenpunkte – Konsumenten dieser Anlaufstelle – und synchronisieren sich mit diesem zentralen Ort.

Centralized workflow
Abbildung 53. Zentralisierter Workflow

Das bedeutet, wenn zwei Entwickler vom Hub klonen und beide Änderungen vornehmen, kann der erste Entwickler, der seine Änderungen zurückschreibt, dies ohne Probleme tun. Der zweite Entwickler muss die Arbeit des ersten zusammenführen, bevor er seine Änderungen hochlädt, um die Änderungen des ersten Entwicklers nicht zu überschreiben. Dieses Konzept ist in Git genauso wahr wie in Subversion (oder jedem CVCS), und dieses Modell funktioniert in Git perfekt.

Wenn Sie mit einem zentralisierten Workflow in Ihrem Unternehmen oder Team bereits vertraut sind, können Sie diesen Workflow problemlos mit Git fortsetzen. Richten Sie einfach ein einziges Repository ein und geben Sie allen in Ihrem Team Push-Zugriff; Git wird nicht zulassen, dass Benutzer sich gegenseitig überschreiben.

Nehmen wir an, John und Jessica beginnen gleichzeitig zu arbeiten. John beendet seine Änderung und pusht sie auf den Server. Dann versucht Jessica, ihre Änderungen zu pushen, aber der Server lehnt sie ab. Ihr wird mitgeteilt, dass sie versucht, Nicht-Fast-Forward-Änderungen zu pushen, und dass sie dies erst tun kann, wenn sie fetched und mergt. Dieser Workflow ist für viele attraktiv, da es sich um ein Paradigma handelt, das vielen vertraut und angenehm ist.

Dies ist auch nicht auf kleine Teams beschränkt. Mit dem Branching-Modell von Git ist es möglich, dass Hunderte von Entwicklern gleichzeitig an einem einzigen Projekt über Dutzende von Branches arbeiten.

Integrationsmanager-Workflow

Da Git Ihnen erlaubt, mehrere entfernte Repositories zu haben, ist es möglich, einen Workflow zu haben, bei dem jeder Entwickler Schreibzugriff auf sein eigenes öffentliches Repository und Lesezugriff auf die Repositories aller anderen hat. Dieses Szenario beinhaltet oft ein kanonisches Repository, das das "offizielle" Projekt darstellt. Um zu diesem Projekt beizutragen, erstellen Sie Ihren eigenen öffentlichen Klon des Projekts und pushen Ihre Änderungen dorthin. Dann können Sie dem Maintainer des Hauptprojekts eine Anfrage senden, Ihre Änderungen zu pullen. Der Maintainer kann dann Ihr Repository als Remote hinzufügen, Ihre Änderungen lokal testen, sie in seinen Branch mergen und zurück in sein Repository pushen. Der Prozess funktioniert wie folgt (siehe Integrationsmanager-Workflow)

  1. Der Projektverantwortliche pusht in sein öffentliches Repository.

  2. Ein Mitwirkender klont dieses Repository und nimmt Änderungen vor.

  3. Der Mitwirkende pusht in seine eigene öffentliche Kopie.

  4. Der Mitwirkende sendet dem Maintainer eine E-Mail mit der Bitte, die Änderungen zu pullen.

  5. Der Maintainer fügt das Repository des Mitwirkenden als Remote hinzu und mergt lokal.

  6. Der Maintainer pusht die gemergten Änderungen in das Haupt-Repository.

Integration-manager workflow
Abbildung 54. Integrationsmanager-Workflow

Dies ist ein sehr gängiger Workflow mit Hub-basierten Tools wie GitHub oder GitLab, wo es einfach ist, ein Projekt zu forken und Ihre Änderungen in Ihren Fork zu pushen, damit jeder sie sehen kann. Einer der Hauptvorteile dieses Ansatzes ist, dass Sie weiterarbeiten können und der Maintainer des Haupt-Repositories Ihre Änderungen jederzeit pullen kann. Mitwirkende müssen nicht darauf warten, dass das Projekt ihre Änderungen übernimmt – jede Partei kann in ihrem eigenen Tempo arbeiten.

Diktator- und Leutnant-Workflow

Dies ist eine Variante eines Multi-Repository-Workflows. Er wird generell von riesigen Projekten mit Hunderten von Mitwirkenden verwendet; ein berühmtes Beispiel ist der Linux-Kernel. Verschiedene Integrationsmanager sind für bestimmte Teile des Repositories verantwortlich; sie werden Leutnants genannt. Alle Leutnants haben einen Integrationsmanager, der als wohlwollender Diktator bekannt ist. Der wohlwollende Diktator pusht von seinem Verzeichnis in ein Referenz-Repository, von dem aus alle Mitwirkenden pullen müssen. Der Prozess funktioniert so (siehe Wohlwollender Diktator-Workflow)

  1. Reguläre Entwickler arbeiten an ihrem Topic-Branch und rebasen ihre Arbeit auf master. Der master-Branch ist der des Referenz-Repositories, in das der Diktator pusht.

  2. Leutnants mergen die Topic-Branches der Entwickler in ihren master-Branch.

  3. Der Diktator mergt die master-Branches der Leutnants in den master-Branch des Diktators.

  4. Schließlich pusht der Diktator diesen master-Branch in das Referenz-Repository, damit die anderen Entwickler darauf basieren können.

Benevolent dictator workflow
Abbildung 55. Wohlwollender Diktator-Workflow

Diese Art von Workflow ist nicht üblich, kann aber bei sehr großen Projekten oder in stark hierarchischen Umgebungen nützlich sein. Sie ermöglicht es dem Projektleiter (dem Diktator), viel Arbeit zu delegieren und große Code-Teilmengen an mehreren Punkten zu sammeln, bevor sie integriert werden.

Muster zur Verwaltung von Quellcode-Branches

Hinweis

Martin Fowler hat eine Anleitung "Patterns for Managing Source Code Branches" erstellt. Diese Anleitung behandelt alle gängigen Git-Workflows und erklärt, wie/wann sie verwendet werden. Es gibt auch einen Abschnitt, der hohe und niedrige Integrationsfrequenzen vergleicht.

https://martinfowler.com/articles/branching-patterns.html

Workflows Zusammenfassung

Dies sind einige gängige Workflows, die mit einem verteilten System wie Git möglich sind, aber Sie können sehen, dass viele Variationen möglich sind, um Ihren spezifischen realen Workflow anzupassen. Nachdem Sie nun hoffentlich bestimmen können, welche Workflow-Kombination für Sie funktionieren könnte, werden wir einige spezifischere Beispiele dafür behandeln, wie die Hauptrollen, aus denen sich die verschiedenen Flows zusammensetzen, umgesetzt werden. Im nächsten Abschnitt lernen Sie einige gängige Muster für die Mitwirkung an einem Projekt kennen.