Der Forking-Workflow unterscheidet sich fundamental von den bislang besprochenen Git-Workflows. In diesen kommt ein einzelnes serverseitiges Repository als zentrale Codebasis zum Einsatz. Im Forking-Workflow jedoch hat jeder Entwickler ein serverseitiges Repository. Jeder Beteiligte arbeitet also mit zwei Repos: einer privaten, lokalen Instanz und einer öffentlichen auf Server-Seite.
Der größte Vorteil des Forking-Workflows ist der, dass Änderungen integriert werden können, ohne dass jeder sie in ein einzelnes zentrales Repository pushen muss. Entwickler pushen stattdessen in ihre eigenen serverseitigen Repositories und nur der Projekt-Maintainer kann Änderungen in das offizielle Repository integrieren. Dadurch kann dieser Commits von allen möglichen Entwicklern akzeptieren, ohne ihnen Schreibzugriff auf die offizielle Codebasis zu geben.
Das Ergebnis ist ein verteilter Workflow, der großen, organischen Teams (inklusive Drittparteien) eine Möglichkeit bietet, sicher zusammenzuarbeiten. Dieser Workflow ist auch eine ideale Lösung für Open-Source-Projekte.
So funktioniert's
Wie die anderen Workflows beginnt auch der Forking-Workflow mit einem offiziellen öffentlichen Repository, das auf einem Server gespeichert ist. Aber wenn ein Entwickler an dem Projekt arbeiten möchte, muss er das offizielle Repo nicht direkt klonen.
Stattdessen wird das offizielle Repository geforkt, um eine Kopie auf dem Server zu erzeugen. Diese neue Kopie dient als persönliches öffentliches Repository – andere Entwickler können keine Änderungen pushen, jedoch Änderungen herunterziehen. Nach der Erzeugung 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, pusht er diesen in sein eigenes öffentliches Repository, nicht in das offizielle. Dann erstellt er einen Pull-Request, damit der Projekt-Maintainer weiß, dass ein Update zur Integration in das Haupt-Repository bereitsteht. Zudem bildet der Pull-Request eine praktische Umgebung für Diskussionen zum beigetragenen Code.
Um das Feature in die offizielle Codebasis zu integrieren, zieht der Projekteigner die Änderungen in sein lokales Repository, überprüft, ob sie sich fehlerfrei in den bisherigen Projektstand einpflegen lassen, mergt sie in seinen lokalen Master-Branch und pusht diesen dann in das offizielle Repository auf dem Server. Der Beitrag ist nun Bestandteil des Projekts; andere Entwickler sollten diesen Projektstand vom offiziellen Repository ziehen, um ihre lokalen Repositories zu synchronisieren.
Das offizielle Repository
Es ist wichtig zu verstehen, dass es sich lediglich um eine Konvention handelt, wenn im Forking-Workflow von einem "offiziellen" Repository die Rede ist. Aus technischer Perspektive gibt es keine Unterschiede zwischen den Repositories der einzelnen Entwickler und dem offiziellen. Was das offizielle Repo offiziell macht, ist schlicht der Fakt, dass es das des Projekt-Maintainers ist.
Branching im Forking-Workflow
All diese persönlichen öffentlichen Repositories bilden einfach einen bequemen Weg, um Branches mit anderen Entwicklern zu teilen. Alle sollten Branches nutzen, um individuelle Features zu isolieren – genau wie im Feature-Branch- und im Gitflow-Workflow. Der Unterschied besteht darin, wie die Branches geteilt werden. Während sie in jenen Workflows in das offizielle Repository gepusht werden, sieht der Forking-Workflow vor, dass sie in die lokalen Repos anderer Entwickler gezogen werden.
Der Folgeartikel zeigt die Zusammenarbeit nach dem Forking-Workflow am konkreten Beispiel.
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
