Git-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 Gitflow-Workflow basiert. Ziel dabei ist, abgeschlossene Feature-Branches in das ursprüngliche 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 funktioniert "git revert"?
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. Sie 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.
Zugehöriges Material
Git-Protokoll für Fortgeschrittene
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
1. Ein Entwickler "forkt" ein "offizielles" serverseitiges Repository. Dadurch wird seine eigene serverseitige Kopie erstellt.
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 eine Pull-Anfrage zum "offiziellen" Repository.
9. Die Pull-Anfrage wird zum Mergen genehmigt und in das ursprüngliche serverseitige Repository gemergt.
Um das Feature in die offizielle Codebasis zu integrieren, führt der Maintainer einen Pull der Änderungen des Beitragenden in das eigene lokale Repository durch, prüft dann, ob sie sich fehlerfrei in das Projekt integrieren lassen, mergt sie in seinen lokalen main-Branch und pusht den main-Branch dann in das offizielle Repository auf dem Server. Der Beitrag ist nun Bestandteil des Projekts und andere Entwickler sollten für diesen Projektstand einen Pull vom offiziellen Repository durchführen, 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 Git-Service eines Drittanbieters 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
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
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.
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.gitEin 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/repoDas 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.gitBenutzer 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 some-feature # Edit some code git commit -a -m "Add first draft of some feature"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 mainDa Entwickler in einem dedizierten Feature Branch arbeiten sollten, sollte dies zu einem Fast-Forward-Merge führen.
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-branchDies 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-Anfrage-Schaltfläche, die zu einem Formular führt, in dem der Entwickler spezifizieren kann, welcher Branch in das offizielle Repository gemergt werden soll. Normalerweise geht es darum, den feature-Branch in den main-Branch der Upstream-Remote-Verbindung zu integrieren.
Zusammenfassung
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/DeinName/offenes-projekt.
3. Führe auf deinem lokalen System git clone für https://bitbucket.org/DeinName/offenes-projekt 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-Anfrage 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.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
