Git-Workflows verzweigen

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.

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.

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.

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.

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:

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.

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:

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

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

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:

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

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:

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-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.

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.