Erkunden des Fork-Workflows
Der Forking-Workflow unterscheidet sich grundlegend von anderen gängigen Git-Workflows.
Anstatt ein einzelnes serverseitiges Repository als „zentrale“ Codebasis zu verwenden, erhalten alle Entwickler ihr serverseitiges Repository.
Dies bedeutet, dass jeder Mitwirkende über zwei Git-Repositorys verfügt:
- Ein privates lokales Repository.
- Ein öffentliches serverseitiges Repository.
Der Forking-Workflow wird am häufigsten in öffentlichen Open-Source-Projekten verwendet.
Der Hauptvorteil des Forking-Workflows besteht darin, dass Beiträge integriert werden können, ohne dass alle Entwickler in ein zentrales Repository pushen müssen.
Entwickler pushen in ihre serverseitigen Repositorys, und nur der Projektbetreuer kann in das offizielle Repository pushen.
Dies ermöglicht es dem Verwalter, Commits von Entwicklern zu akzeptieren, ohne ihnen Schreibzugriff auf die offizielle Codebasis zu erteilen.
Der Forkworkflow ist in der Regel für das Mergen im Repository des ursprünglichen Projektbetreuers vorgesehen.
Das Ergebnis ist ein verteilter Workflow, der großen, organischen Teams (einschließlich nicht vertrauenswürdiger Dritter) eine flexible Möglichkeit zur sicheren Zusammenarbeit bietet.
Dies macht sie auch zu einem idealen Workflow für Open-Source-Projekte.
Funktionsweise
Wie bei den anderen Git-Workflows beginnt der Forking-Workflow mit einem offiziellen öffentlichen Repository, das auf einem Server gespeichert ist.
Wenn ein neuer Entwickler jedoch mit der Arbeit am Projekt beginnen möchte, klont er das offizielle Repository nicht direkt.
Stattdessen forkt er das offizielle Repository, um eine Kopie davon auf dem Server zu erstellen.
Diese neue Kopie dient als persönliches öffentliches Repository. Keine anderen Entwickler können es pushen, aber sie können Änderungen daraus pullen (wir werden gleich erfahren, warum das notwendig ist).
Nachdem sie ihre serverseitige Kopie erstellt haben, führt der Entwickler einen „git clone“-Befehl aus, um eine Kopie davon auf seinen lokalen Computer abzurufen.
Diese fungiert wie in den anderen Workflows als private Entwicklungsumgebung.
Wenn der Entwickler bereit ist, einen lokalen Commit zu veröffentlichen, pusht er den Commit in sein öffentliches Repository – nicht in das offizielle.
Anschließend stellt er einen Pull Request für das Hauptrepository aus, damit der Projektbetreuer weiß, dass ein Update für die Integration bereit ist.
Der Pull Request dient auch als praktischer Diskussionsthema, wenn Probleme mit dem beigetragenen Code vorliegen.
Im Folgenden finden Sie ein Schritt-für-Schritt-Beispiel für diesen Workflow:
- Ein Entwickler „forkt“ ein „offizielles“ serverseitiges Repository. Dadurch wird die serverseitige Kopie erstellt.
- Die neue serverseitige Kopie wird in ihr lokales System geklont.
- Dem lokalen Klon wird ein Git-Remotepfad für das „offizielle“ Repository hinzugefügt.
- Es wird ein neuer lokaler Featurebranch erstellt.
- Der Entwickler nimmt Änderungen am neuen Branch vor.
- Für die Änderungen werden neue Commits erstellt.
- Der Branch wird zur serverseitigen Kopie des Entwicklers gepusht.
- Der Entwickler öffnet einen Pull Request aus dem neuen Branch zum „offiziellen“ Repository.
- Der Pull Request wird für die Zusammenführung genehmigt und mit dem ursprünglichen serverseitigen Repository zusammengeführt.
So integrieren Sie das Feature in die offizielle Codebasis:
- Der Betreuer pullt die Änderungen des Mitwirkenden in sein lokales Repository.
- Er führt Prüfungen durch, um sicherzustellen, dass das Projekt nicht beeinträchtigt wird.
- Es wird dann in den lokalen Mainbranch zusammengeführt.
- Der Mainbranch wird dann in das offizielle Repository auf dem Server gepusht.
Der Beitrag ist jetzt Teil des Projekts, und andere Entwickler sollten aus dem offiziellen Repository pullen, um ihre lokalen Repositorys zu synchronisieren.
Es ist wichtig zu verstehen, dass der Begriff eines „offiziellen“ Repositorys im Forking-Workflow lediglich eine Konvention ist.
Das offizielle Repository wird nur deshalb als „offiziell“ betrachtet, da es das Repository des Projektbetreuers ist.
Forking im Vergleich zum Klonen
Es ist wichtig zu wissen, dass „geforkte“ Repositorys und „Forking“ keine speziellen Vorgänge sind.
Geforkte Repositorys werden mithilfe des Standardbefehls „git clone“ erstellt. Geforkte Repositorys sind im Allgemeinen „serverseitige Klone“, die von einem Git-Dienstanbieter wie Azure Repos verwaltet und gehostet werden.
Es gibt keinen eindeutigen Git-Befehl zum Erstellen geforkter Repositorys.
Ein Klonvorgang ist im Wesentlichen eine Kopie eines Repositorys und seines Verlaufs.