Git 🌙
Chapters ▾ 2nd Edition

5.1 Verteiltes Git - Verteilter Arbeitsablauf

Nachdem du ein entferntes Git-Repository eingerichtet hast, in dem alle Entwickler ihren Code teilen können, und du mit den grundlegenden Git-Befehlen in einem lokalen Arbeitsablauf vertraut bist, wirst du einige der verteilten Arbeitsabläufe verwenden, die Git dir ermöglicht.

In diesem Kapitel erfährst du, wie du mit Git in einer verteilten Umgebung als Mitwirkender (engl. Contributor) und Integrator arbeitest. Das heißt, du lernst, wie du Quelltext erfolgreich zu einem Projekt beisteuern und es dir und dem Projektbetreuer so einfach wie möglich machst. Außerdem lernst du, wie du ein Projekt erfolgreich verwaltest, in dem mehrere Entwicklern Inhalte beisteuern.

Verteilter Arbeitsablauf

Im Gegensatz zu CVCSs (Centralized Version Control Systems – Zentrale Versionsverwaltungs Systeme) kannst du dank der verteilten Struktur von Git die Zusammenarbeit von Entwicklern in Projekten wesentlich flexibler gestalten. In zentralisierten Systemen ist jeder Entwickler ein gleichwertiger Netzknoten, der mehr oder weniger gleichermaßen mit einem zentralen System arbeitet. In Git ist jedoch jeder Entwickler potentiell beides – sowohl Netzknoten als auch zentrales System. Das heißt, jeder Entwickler kann sowohl Code für andere Repositorys bereitstellen als auch ein öffentliches Repository verwalten, auf dem andere ihre Arbeit aufbauen und zu dem sie beitragen können. Dies bietet eine Fülle von möglichen Arbeitsabläufen (engl. Workflows) für dein Projekt und/oder deinem Team, sodass wir einige gängige Paradigmen behandeln, welche die Vorteile dieser Flexibilität nutzen. Wir werden auf die Stärken und möglichen Schwächen der einzelnen Entwürfe eingehen. Du kannst einen einzelnen davon auswählen, um ihn zu nutzen, oder du kannst die Funktionalitäten von allen miteinander kombinieren.

Zentralisierter Arbeitsablauf

In zentralisierten Systemen gibt es im Allgemeinen ein einziges Modell für die Zusammenarbeit – den zentralisierten Arbeitsablauf. Ein zentraler Hub oder Repository kann Quelltext akzeptieren und alle Beteiligten synchronisieren ihre Arbeit damit. Eine Reihe von Entwicklern sind Netzknoten – Nutzer dieses Hubs – und synchronisieren ihre Arbeit mit diesem einen, zentralen Punkt.

Zentralisierter Arbeitsablauf
Abbildung 53. Zentralisierter Arbeitsablauf

Dies bedeutet, wenn zwei Entwickler ein Repository vom Hub klonen und beide Änderungen vornehmen, kann der erste Entwickler seine Änderungen problemlos zurückspielen (pushen). Der zweite Entwickler muss jedoch die Arbeit des ersten Entwicklers bei sich einfließen lassen (mergen), bevor seine Änderungen aufgenommen werden können, damit die Änderungen des ersten Entwicklers nicht überschrieben werden. Dieses Konzept ist in Git genauso wahr wie in Subversion (oder ein anderes beliebiges CVCS), und dieses Konzept funktioniert in Git wunderbar.

Wenn du bereits mit einem zentralisierten Arbeitsablauf in deinem Unternehmen oder Team vertraut bist, kannst du diesen Ablauf problemlos mit Git weiterverwenden. Richte einfach ein einziges Repository ein und gewähre allen Mitgliedern deines Teams Schreib-Zugriff (push). Git lässt nicht zu, dass Benutzer ihre Änderungen gegenseitig überschreiben.

Sagen wir, John und Jessica fangen beide zur gleichen Zeit mit ihrer Arbeit an. John beendet seine Änderung und lädt diese zum Server hoch. Dann versucht Jessica, ihre Änderungen hochzuladen, aber der Server lehnt sie ab. Ihr wird gesagt, dass sie versucht, Änderungen „non-fast-forward“ zu pushen, und dass sie dies erst tun kann, wenn sie die bestehenden Änderungen abgeholt und mit ihrer lokalen Kopie zusammengeführt hat. Dieser Workflow ist für viele Menschen sehr ansprechend, weil er ein bewährtes Modell ist, mit dem viele bereits bekannt und vertraut sind.

Diese Vorgehensweise ist nicht auf kleine Teams beschränkt. Mit dem Verzweigungs-Modell (Branching-Modell) von Git ist es Hunderten von Entwicklern möglich, ein einzelnes Projekt über Dutzende von Branches gleichzeitig erfolgreich zu bearbeiten.

Arbeitsablauf mit Integrationsmanager

Da du in Git über mehrere Remote-Repositorys verfügen kannst, ist ein Workflow möglich, bei dem jeder Entwickler Schreibzugriff auf sein eigenes, öffentliches Repository und Lesezugriff auf die Repositorys aller anderen Entwickler hat. Dieses Szenario enthält häufig ein zentrales Repository, das das „offizielle“ Projekt darstellt. Um zu diesem Projekt beizutragen, erstellst du deinen eigenen öffentlichen Klon des Projekts und lädst deine Änderungen dort hoch. Anschließend kannst du eine Anfrage an den Betreuer des Hauptprojekts senden, um deine Änderungen zu übernehmen (Pull Request). Der Betreuer kann dann dein Repository als Remote hinzufügen, deine Änderungen lokal testen, diese in seinem Branch einfließen lassen und in sein öffentliches Repository hochladen. Der Prozess funktioniert wie folgt (siehe Arbeitsablauf mit Integrationsmanager):

  1. Die Projekt Betreuer laden Arbeit in ihr eigenes, öffentlichen Repository hoch.

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

  3. Der Mitwirkende lädt diese in sein eigenes öffentliches Repository hoch.

  4. Der Mitwirkende sendet dem Betreuer eine E-Mail mit der Aufforderung, die Änderungen zu übernehmen (Pull Request).

  5. Der Betreuer fügt das Repository des Mitwirkenden als Remote hinzu und führt die Änderungen lokal zusammen.

  6. Der Betreuer lädt die zusammengeführten Änderungen in das Haupt-Repository hoch.

Arbeitsablauf mit Integrationsmanager
Abbildung 54. Arbeitsablauf mit Integrationsmanager

Dies ist ein sehr häufiger Workflow mit Hub-basierten Tools wie GitHub oder GitLab, bei dem es einfach ist, ein Projekt zu „forken“ und eigene Änderungen in deinen Fork hochzuladen, damit jeder sie sehen kann. Einer der Hauptvorteile dieses Ansatzes besteht darin, dass du weiterarbeiten kannst und der Verwalter des Haupt-Repositorys deine Änderungen jederzeit übernehmen kann. Die Mitwirkenden müssen nicht warten, bis das Projekt deine Änderungen übernommen hat – jede Partei kann in ihrem eigenen Tempo arbeiten.

Arbeitsablauf mit Diktator und Leutnants

Dies ist eine Variante eines Workflows mit vielen Repositorys. Sie wird im Allgemeinen von großen Projekten mit Hunderten von Mitstreitern verwendet. Ein berühmtes Beispiel ist der Linux-Kernel. Verschiedene Integrationsmanager sind für bestimmte Teile des Repositorys verantwortlich. Sie heißen Leutnants. Alle Leutnants haben einen Integrationsmanager, der als der wohlwollende Diktator (benevolent dictator) bezeichnet wird. Der wohlwollende Diktator pusht von seinem Verzeichnis in ein Referenz-Repository, aus dem alle Beteiligten ihre eigenen Repositorys aktualisieren müssen. Dieser Prozess funktioniert wie folgt (siehe Arbeitsablauf mit wohlwollendem Diktator):

  1. Entwickler arbeiten regelmäßig an ihrem Featurebranch und reorganisieren (rebasen) ihre Arbeit auf master. Der master Branch ist der des Referenz-Repositorys, in das der Diktator pusht.

  2. Die Leutnants mergen die Featurebranches der Entwickler in ihrem master Branch.

  3. Der Diktator führt die master Branches der Leutnants in den Branch master des Diktators zusammen.

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

Arbeitsablauf mit wohlwollendem Diktator
Abbildung 55. Arbeitsablauf mit wohlwollendem Diktator

Diese Art von Arbeitsablauf ist nicht weit verbreitet, kann jedoch in sehr großen Projekten oder in sehr hierarchischen Umgebungen hilfreich sein. Dies ermöglicht dem Projektleiter (dem Diktator), einen Großteil der Arbeit zu delegieren und große Teilbereiche von Quelltext an mehreren Stellen zu sammeln, bevor diese integriert werden.

Methoden zur Verwaltung von Quellcode-Branches

Anmerkung

Martin Fowler hat den Leitfaden „Patterns for Managing Source Code Branches“ (Methoden zur Verwaltung von Quellcode-Branches) erstellt. Dieser Leitfaden deckt alle gängigen Git-Workflows ab und erklärt, wie und wann sie eingesetzt werden sollten. Es gibt auch einen Abschnitt, in dem hohe und niedrige Integrationsfrequenzen verglichen werden.

Zusammenfassung

Dies sind einige häufig verwendete Workflows, die mit einem verteilten System wie Git möglich sind. Allerdings sind auch viele Variationen möglich, um deinen eigenen Arbeitsabläufen gerecht zu werden. Jetzt, da du (hoffentlich) bestimmen kannst, welche Kombination von Arbeitsabläufen bei dir funktionieren würde, werden wir einige spezifischere Beispiele davon betrachten, wie man die Hauptaufgaben durchführen kann, welche die unterschiedliche Abläufe ausmachen. Im nächsten Abschnitt erfährst du etwas über gängige Formen der Mitarbeit an einem Projekt.

scroll-to-top