Git-Workflows: Der Forking-Workflow (Teil 2)

Die Grundlagen des Forking-Workflows für Teams, die Git als verteilte Versionskontrolle nutzen, wurden im vorangehenden Artikel umrissen. Nun folgt ein konkretes Beispiel, das zeigt, wie Entwickler nach diesem Prozess zusammenarbeiten können.

Der Projekt-Maintainer initialisiert das offizielle Repository

Git Forking-Workflow 2

Wie in jedem Git-basierten Projekt besteht der erster Schritt darin, auf einem Server ein offizielles Repository zu erstellen, das allen Teammitgliedern zugänglich ist. Dieses Repository dient auch als öffentliches Repo des Projekt-Maintainers.

Um dieses Repository, die "bare" sein sollte, aufzusetzen, führt der Maintainer diese Kommandos aus:

ssh user@host
git init --bare /path/to/repo.git

Bitbucket und Stash bieten über ihre Oberflächen auch bequeme Alternativen zu diesen Befehlen. Der Prozess entspricht jedenfalls exakt denen in den bislang beschriebenen Workflows. Anschließend sollte der Projekt-Maintainer die bestehende Codebasis in dieses Repository pushen, wenn nötig.

Entwickler forken das offizielle Repository

Git Forking-Workflow 3

Als nächstes müssen alle Entwickler dieses offizielle Repository forken. Das ist möglich, indem sie sich per SSH am Server anmelden und git clone ausführen, um das Repo an eine andere Stelle auf dem Server zu kopieren. Forking entspricht grundsätzlich also dem serverseitigen Klonen. Auch hier bieten Bitbucket und Stash bequeme Buttons, um ein Repository zu forken.

Anschließend sollten alle Entwickler ihre eigenen serverseitigen Repositories haben.

Entwickler klonen ihre geforkten Repositories

Git Forking-Workflow 4

Nun müssen alle Entwickler ihre eigenen öffentlichen Repositories klonen. Das geschieht über das vertraute Kommando git clone.

In diesem Beispiel wird Bitbucket genutzt, um die Repositories zu hosten. In dieser Situation sollte jeder Entwickler seinen eigenen Bitbucket-Account haben und wie folgt jeweils ein eigenes serverseitiges Repo anlegen:

git clone https://user@bitbucket.org/user/repo.git

Der Forking-Workflow erfordert zwei Remote-Verbindungen – eine für das offizielle Repository und eine für das persönliche serverseitige Repo des Entwicklers. Nach einer üblichen Konvention werden für diese Remote-Verbindungen die Bezeichnungen Upstream und origin verwendet.

git remote add upstream https://bitbucket.org/maintainer/repo

Die Upstream-Verbindung muss mit dem Befehl oben manuell erstellt werden. So ist es einfach, das lokale Repository aktuell zu halten, wenn das offizielle Projekt voranschreitet. Da in diesem Beispiel für das Upstream-Repository eine Authentifizierung nötig ist (es ist also kein Open-Source-Projekt), muss der User-Name übermittelt werden:

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

Somit muss der Nutzer ein gültiges Passwort übertragen, wenn er die offizielle Codebasis klont oder herunterzieht.

Entwickler arbeiten an ihren Features

Git Forking-Workflow 5

In den lokalen Repositories, die sie gerade geklont haben, können die Entwickler Code editieren, Änderungen committen und Branches erzeugen, ganz wie in den anderen Workflows:

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

Alle Änderungen eines Entwicklers sind privat, bis er sie in sein öffentliches Repository pusht. Wenn das offizielle Projekt voranschreitet, kann er auf neue Commits via git pull zugreifen:

git pull upstream master

Da Entwickler hier typischerweise jeweils in einem dedizierten Feature-Branch arbeiten, sollte dies in Fast-Forward-Merges resultieren.

Entwickler veröffentlichen ihre Features

Git Forking-Workflow 6

Sobald ein Entwickler bereit ist, sein neues Feature zu teilen, stehen zwei Schritte an. Erstens muss er seinen Beitrag den anderen Entwicklern zugänglich machen, indem er ihn in sein öffentliches Repository pusht. Da die origin-Remote-Verbindung bereits aufgesetzt ist, genügt das folgende Kommando:

git push origin feature-branch

Dies unterscheidet sich insofern von den anderen Workflows, dass die origin-Remote-Verbindung auf das persönliche serverseitige Repo des Entwicklers verweist und nicht auf die Haupt-Codebasis.

Zweitens muss der Projekt-Maintainer informiert werden, dass das neue Feature in die offizielle Codebasis gemergt werden kann. Bitbucket und Stash bieten einen Pull-Request-Button, der zu einem Formular führt, in dem der Entwickler spezifizieren kann, welcher Branch gemergt werden soll. Normalerweise geht es darum, den Feature-Branch in den Master-Branch der Upstream-Remote-Verbindung zu integrieren.

Der Projekt-Maintainer integriert die Features

Git Forking-Workflow 7

Wenn der Projekt-Maintainer den Pull-Request erhält, hat er die Aufgabe zu entscheiden, ob die Integration in die offizielle Codebasis erfolgen soll oder nicht. Hier hat er zwei Möglichkeiten:

  1. Er inspiziert den Code direkt im Pull-Request.
  2. Er zieht den Code in sein lokales Repository und mergt ihn manuell.

Die erste Option ist einfacher, da der Projekt-Maintainer eine Diff-Ansicht der Änderungen zur Verfügung hat, sie kommentieren und über eine grafische Benutzeroberfläche mergen kann. Allerdings muss er die zweite Option wählen, wenn der Pull-Request einen Merge-Konflikt auslöst. In diesem Fall holt er den Feature-Branch mit fetch vom serverseitigen Repository des Entwicklers, mergt ihn in seinen lokalen Master-Branch und löst die Konflikte auf:

git fetch https://bitbucket.org/user/repo feature-branch
# Inspect the changes
git checkout master
git merge FETCH_HEAD

Sind die Änderungen in den lokalen Master-Branch integriert, muss der Projekt-Maintainer ihn in das offizielle Repository auf der Server pushen, sodass andere Entwickler Zugriff darauf erhalten:

git push origin master

Da origin beim Projekt-Maintainer auf dessen öffentliches Repository zeigt, das auch als offizielle Codebasis des Projekts dient, ist der Beitrag des Entwicklers nun voll in dieses integriert.

Entwickler synchronisieren sich mit dem offiziellen Repository

Git Forking-Workflow 8

Da die Haupt-Codebasis damit nun weiterentwicklt wurde, sollten die anderen Entwickler sich mit dem offiziellen Repository synchronisieren:

git pull upstream master

Fazit

Für Entwickler mit einem SVN-Backround mag der Forking-Workflow wie ein radikaler Paradigmenwechsel wirken. Doch im Grunde fügt dieser Prozess dem Feature-Branch-Workflow nur eine weitere Abstraktionsebene hinzu. Statt Branches direkt in ein einzelnes zentrales Repository zu teilen, werden Änderungen serverseitigen Repositories veröffentlicht, die den einzelnen Entwicklern gehören.

Dieser Artikel beschreibt, wie eine Änderung von einem Entwickler in den offiziellen Master-Branch gelangt. Doch dieselbe Methode kann genutzt werden, um eine Änderung in jedes beliebige Repository zu integrieren. Wenn ein Team beispielsweise zusammen an einem bestimmten Feature arbeitet, kann es Änderungen auf exakt dieselbe Weise innerhalb des Teams teilen – ohne das Haupt-Repository zu tangieren.

Das macht den Forking-Workflow zu einem mächtigen Prozess für eher lose verknüpfte Teams. Jeder Entwickler kann Änderungen ganz einfach mit anderen teilen und jeder Branch kann effizient in die offizielle Codebasis gemergt werden.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash von Atlassian? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.

Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

Git und Stash in der Software-Entwicklung: Eine Einführung
Stash in der Praxis
Stash Enterprise: Git-Repository-Management in großen Unternehmen
So funktioniert die Lizenzierung von Atlassian-Produkten

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar