Workflows verzweigen

 

Der Forking-Workflow unterscheidet sich vollkommen von anderen beliebten Git-Workflows. Anstatt ein einzelnes serverseitiges Repository als zentrale Codebasis zu verwenden, bietet er jedem Entwickler ein eigenes serverseitiges Repository. Jeder Beteiligte arbeitet also nicht mit einem sondern zwei Git-Repositorys: einem privaten, lokalen und einem öffentlichen auf Serverseite. Der Forking-Workflow findet vor allem in öffentlichen Open-Source-Projekten Anwendung.

Der größte Vorteil des Forking-Workflows ist: Beiträge können integriert werden, ohne dass alle sie in ein einziges zentrales Repository pushen müssen. Entwickler pushen stattdessen in ihre eigenen serverseitigen Repositorys und nur der Projekt-Maintainer kann in das offizielle Repository pushen. Dadurch kann dieser Commits von allen möglichen Entwicklern akzeptieren, ohne ihnen Schreibzugriff auf die offizielle Codebasis zu geben.

Der Forking-Workflow entspricht üblicherweise einem Branching-Modell, das auf dem Git-flow-Workflow basiert. Ziel dabei ist, abgeschlossene Feature Branches in das eigentliche Projekt-Repository des Maintainers zu mergen. Als Ergebnis entsteht ein verzweigter Workflow, der großen, organischen Teams (einschließlich nicht vertrauenswürdigen Dritten) Flexibilität zum sicheren Zusammenarbeiten bietet. Damit eignet sich der Workflow auch ideal für Open-Source-Projekte.
 

Wie es funktioniert

Wie auch andere Git-Workflows basiert der Forking-Workflow auf einem offiziellen öffentlichen Repository, das auf einem Server gespeichert ist. Wenn jedoch ein neuer Entwickler beginnt, an dem Projekt zu arbeiten, klont er das offizielle Repository nicht direkt.

Stattdessen forken sie das offizielle Repository, um eine Kopie davon auf dem Server zu erstellen. Diese neue Kopie dient als persönliches, öffentliches Repository – keine anderen Entwickler dürfen darauf pushen, sie können aber Änderungen von dort pullen (warum das wichtig ist, sehen wir gleich). Nach der Erstellung der serverseitigen Kopie führt der Entwickler git clone aus, um eine Kopie auf seine lokale Maschine zu ziehen. Diese dient als seine private Entwicklungsumgebung, genau wie in den anderen Workflows.

Ist er bereit, einen lokalen Commit zu veröffentlichen, verschiebt er den Commit in sein eigenes öffentliches Repository – und nicht in das offizielle. Dann sendet er einen Pull-Request für das Haupt-Repository und der Projekt-Maintainer weiß, dass eine Aktualisierung zur Integration bereitsteht. Der Pull-Request dient auch als praktischer Diskussions-Thread, wenn Issues mit Codebeiträgen auftreten. Im Folgenden führe ich Schritt für Schritt ein Beispiel dieses Workflows vor.

 

  1. Ein Entwickler "forkt" ein "offizielles" serverseitiges Repository. So erstellt er seine eigene serverseitige Kopie.
  2. Die neue serverseitige Kopie wird auf das lokale System geklont.
  3. Für das "offizielle" Repository wird dem lokalen Klon ein Remote-Pfad in Git hinzugefügt.
  4. Ein neuer lokaler Feature Branch wird erstellt.
  5. Der Entwickler nimmt Änderungen am neuen Branch vor.
  6. Für die Änderungen werden neue Commits erstellt.
  7. Der Branch wird in die private serverseitige Kopie des Entwicklers gepusht.
  8. Der Entwickler startet vom neuen Branch ausgehend einen Pull-Request zum "offiziellen" Repository.
  9. Der Pull-Request wird zum Mergen genehmigt und wird in das ursprüngliche serverseitige Repository gemergt.
     

Um das Feature in die offizielle Codebasis zu integrieren, pullt der Maintainer die Änderungen des Beteiligten in das eigene lokale Repository, prüft dann, ob sie sich fehlerfrei in das Projekt integrieren lassen, mergt sie in seinen lokalen Master Branch und pusht den Master Branch dann in das offizielle Repository auf dem Server. Der Beitrag ist nun Bestandteil des Projekts und andere Entwickler sollten diesen Projektstand vom offiziellen Repository pullen, um ihre lokalen Repositorys zu synchronisieren.

Es ist wichtig zu verstehen, dass die Vorstellung eines "offiziellen" Repositorys im Forking-Workflow reine Festlegungssache ist. Das offizielle Repository ist einfach deshalb das offizielle, weil es das offizielle Repository des Projekt-Maintainers ist.

Forken vs. Klonen

Wichtig zu wissen ist, dass "geforkte" Repositorys und das "Forken" keine gesonderten Vorgänge sind. Geforkte Repositorys erstellst du mit dem Standardbefehl git clone. Geforkte Repositorys sind für gewöhnlich "serverseitige Klone" und werden normalerweise von einem dritten Git-Service wie Bitbucket verwaltet und gehostet. Es gibt keinen speziellen Git-Befehl zum Forken von Repositorys. Das Klonen ist im Grunde genommen dasselbe wie das Kopieren eines Repositorys samt Verlauf. 

Branching in verteilten Workflows

All diese persönlichen öffentlichen Repositorys sind einfach eine praktische Methode, um Branches mit anderen Entwicklern zu teilen. Alle sollten Branches nutzen, um individuelle Features zu isolieren – genau wie im Feature Branch- und im Git-flow-Workflow. Der Unterschied besteht darin, wie die Branches geteilt werden. Während sie in den Feature Branch- und Git-flow-Workflows in das offizielle Repository gepusht werden, sieht der Forking-Workflow vor, dass sie in die lokalen Repositorys anderer Entwickler gepusht werden.

Ein Repository forken

Forking-Workflow mit Git – Ein Repository forken

In einem Projekt mit einem Forking-Workflow müssen alle neuen Entwickler das offizielle Repository forken. Forken ist, wie bereits erwähnt, nichts anderes als ein standardmäßiger git clone-Vorgang. Das ist möglich, indem du dich per SSH am Server anmeldest und git clone ausführst, um eine Kopie des Repositorys an einem anderen Speicherort auf dem Server abzulegen. Beliebte Hostingservices für Git, wie Bitbucket, bieten Features für Repository-Forking an, um diesen Schritt zu automatisieren.

Den Fork klonen

Als Nächstes müssen alle Entwickler ihr eigenes öffentliches Repository klonen. Das geschieht über den bekannten git clone-Befehl.

Gehen wir davon aus, dass zum Hosten dieser Repositorys Bitbucket eingesetzt wird. Entwickler sollten in einem Projekt ihren eigenen Bitbucket-Account haben und ihre Kopie des Repositorys mit folgendem Befehl forken:

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

Ein Remote-Repository hinzufügen

Während die anderen Workflows eine einzelne origin-Remote-Verbindung nutzen, die zum zentralen Repository verweist, erfordert der Forking-Workflow zwei Remote-Verbindungen – eine für das offizielle Repository und eine für das persönliche serverseitige Repository des Entwicklers. Zwar kannst du diese Remote-Verbindungen nennen wie du willst, es ist aber üblich, origin als Remote-Verbindung für dein geforktes Repository zu verwenden (dieses wird automatisch erstellt, wenn du git clone ausführst) und upstream für das offizielle Repository.

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

Das Upstream-Remote-Repository musst du mit dem obigen Befehl selbst erstellen. So kannst du dein lokales Repository jederzeit unkompliziert mit den Fortschritten aus dem offiziellen Projekt aktuell halten. Wenn für dein Upstream-Repository Authentifizierung aktiviert ist, es also kein Open-Source-Repository ist, musst du wie folgt einen Benutzernamen angeben:

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

Benutzer müssen dabei vor dem Klonen oder Verschieben aus einer offiziellen Codebasis ein gültiges Passwort angeben.

In einem Branch arbeiten: Änderungen vornehmen und pushen

Entwickler können in ihrer lokalen Kopie des geforkten Repositorys Code bearbeiten, Änderungen committen und genau wie in anderen Git-Workflows Branches erstellen:

git checkout -b ein-feature
# Code bearbeiten
git commit -a -m "Ersten Entwurf eines Features hinzufügen"

Alle ihre Änderungen sind privat, bis sie diese in ihre öffentlichen Repositorys pushen. Wenn das offizielle Projekt fortgeschritten ist, können sie mit git pull auf neue Commits zugreifen:

git pull upstream master

Da Entwickler in einem dedizierten Feature Branch arbeiten sollten, sollte dies zu einem Fast-Forward-Merge führen.

Einen Pull Request erstellen

Forking-Workflow mit Git – Einen Pull-Request erstellen

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 das öffentliche Repository pusht. Die origin-Remote-Verbindung sollte bereits eingerichtet sein, deshalb genügt der folgende Befehl:

git push origin feature-branch

Dies unterscheidet sich insofern von den anderen Workflows, dass die origin-Remote-Verbindung auf das persönliche serverseitige Repository 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 bietet eine Pull-Request-Schaltfläche, die 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.

Summary

Fassen wir noch einmal zusammen: Der Forking-Workflow wird vor allem in öffentlichen Open-Source-Projekten genutzt. Forking ist ein git clone-Vorgang, der in einer Serverkopie eines Projekt-Repositorys durchgeführt wird. Bei Forking-Workflows wird oft ein Hostingservice wie Bitbucket genutzt. So könnte ein einfacher Forking-Workflow aussehen:

 

  1. Du möchtest Code zu einer Open-Source-Bibliothek beitragen, die unter bitbucket.org/benutzerA/offenes-projekt gehostet wird.
  2. Mit Bitbucket forkst du das Repository zu bitbucket.org/YourName/open-project.
  3. Führe auf deinem lokalen System git clone für https://bitbucket.org/YourName/open-project aus, um eine lokale Kopie des Repositorys zu erzeugen.
  4. Du erstellst einen neuen Feature Branch in deinem lokalen Repository.
  5. Das neue Feature ist fertiggestellt und die Änderungen wurden mit git commit gespeichert.
  6. Dann pushst du den neuen feature-Branch in dein geforktes Remote-Repository.
  7. Mit Bitbucket eröffnest du für den neuen Branch einen Pull-Request hin zum ursprünglichen Repository unter bitbucket.org/benutzerA/offenes-projekt.
     

 

In einem Forking-Workflow können Projekt-Maintainer ein Repository für Beiträge von anderen Entwicklern zugänglich machen, ohne die Autorisierungseinstellungen für jeden einzelnen Mitwirkenden manuell verwalten zu müssen. Der Maintainer erhält dann eine Art "Pull"-Workflow. Der Forking-Workflow kommt meist in Open-Source-Projekten zur Anwendung, kann aber auch von privaten Unternehmen genutzt werden, die zuverlässig kontrollieren wollen, welcher Code in den Release gemergt wird. Das kann für Teams mit Deploy Managers oder strengen Release-Zyklen nützlich sein.

Nicht sicher, ob dieser Workflow das Richtige für dich ist? Finde es heraus bei unserem umfassenden Vergleich der Git-Workflows.

Du möchtest mit Git arbeiten?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen