Implementieren des Fork-Workflows
Ein „Fork“ ist eine Kopie eines Repositorys. Das Forken eines Repositorys ermöglicht es Ihnen, mit Änderungen zu experimentieren, ohne das ursprüngliche Projekt zu beeinträchtigen.
Am häufigsten werden Forks verwendet, um Änderungen am Projekt einer anderen Person vorzuschlagen. Oder verwenden Sie das Projekt einer anderen Person als Startpunkt für eine eigene Idee.
Ein Fork ist eine vollständige Kopie eines Repositorys, einschließlich aller Dateien, Commits und (optional) Branches.
Forks sind eine hervorragende Möglichkeit, einen Inner-Source-Workflow zu unterstützen: Sie können einen Fork erstellen, um Änderungen vorzuschlagen, wenn Sie nicht die Erlaubnis haben, direkt in das Originalprojekt zu schreiben.
Sobald Sie bereit sind, diese Änderungen freizugeben, können Sie sie ganz einfach mithilfe von Pull Requests wieder einbringen.
Was befindet sich in einem Fork?
Ein Fork beginnt mit dem gesamten Inhalt des (ursprünglichen) Upstreamrepositorys.
Sie können beim Erstellen eines Forks alle Branches einbeziehen oder ihn auf den Standardbranch einschränken.
Keine der Berechtigungen, Richtlinien oder Buildpipelines wird angewendet.
Der neue Fork verhält sich so, als ob jemand das ursprüngliche Repository geklont und es dann in ein neues, leeres Repository gepusht hat.
Nachdem ein Fork erstellt wurde, werden neue Dateien, Ordner und Branches nicht zwischen den Repositorys freigegeben, es sei denn, sie werden von einem Pull Request (PR) mitgenommen.
Freigeben von Code zwischen Forks
Sie können Pull Requests für beide Richtungen erstellen: „Fork zu Upstream“ oder „Upstream zu Fork“.
Der häufigste Ansatz ist „Fork zu Upstream“.
Die Berechtigungen, Richtlinien, Builds und Arbeitselemente des Zielrepositorys gelten für den Pull Request (PR).
Auswählen zwischen Branches und Forks
Für ein kleines Team (2 bis 5 Entwickler) empfehlen wir, in einem einzelnen Repository zu arbeiten.
Jeder sollte in einem Topic-Branch arbeiten, und der Mainbranch sollte durch Branchrichtlinien geschützt werden.
Wenn Ihr Team wesentlich größer wird, kann es sein, dass Sie aus diesem Arrangement herauswachsen und es vorziehen, zu einem Forking-Workflow zu wechseln.
Wir empfehlen den Forking-Workflow, wenn Ihr Repository viele zufällige oder unregelmäßige Ausschüsse hat (wie ein Open-Source-Projekt).
In der Regel haben nur die Hauptmitwirkenden an Ihrem Projekt direkte Commit-Rechte in Ihrem Repository.
Es wäre hilfreich, wenn Sie Projektmitarbeiter außerhalb dieser Kerngruppe auffordern würden, über einen Fork des Repositorys zu arbeiten.
Außerdem werden deren Änderungen von Ihren isoliert, bis Sie die Gelegenheit hatten, die Arbeit zu überprüfen.
Forking-Workflow
- Erstellen Sie einen Fork.
- Klonen Sie ihn lokal.
- Nehmen Sie Ihre Änderungen lokal vor, und pushen Sie sie in einen Branch.
- Erstellen und vervollständigen Sie einen Pull Request zur Upstreamposition.
- Synchronisieren Sie Ihren Fork mit dem neuesten Stand von der Upstreamposition.
Erstellen des Forks
- Navigieren Sie zum Forken zum Repository, und wählen Sie „Fork“ aus.
- Geben Sie einen Namen an, und wählen Sie das Projekt aus, in dem Sie den Fork erstellen möchten. Wenn das Repository viele Topic-Branches enthält, empfehlen wir, nur den Standardbranch zu forken.
- Wählen Sie die Auslassungspunkte und dann „Fork“ aus, um den Fork zu erstellen.
Hinweis
Um einen Fork erstellen zu können, müssen Sie in dem von Ihnen gewählten Projekt über die Berechtigung zum Erstellen von Repositorys verfügen. Wir empfehlen Ihnen, ein dediziertes Projekt für Forks zu erstellen, in dem alle Mitwirkenden über die Berechtigung zum Erstellen von Repositorys verfügen. Ein Beispiel zum Erteilen dieser Berechtigung finden Sie unter „Festlegen von Berechtigungen für Git-Repositorys“.
Lokales Klonen des Forks
Sobald Ihr Fork bereit ist, klonen Sie ihn über die Befehlszeile oder eine integrierte Entwicklungsumgebung (IDE) wie Visual Studio. Der Fork wird zu Ihrem ursprünglichen Remoterepository.
Der Einfachheit halber sollten Sie nach dem Klonen das Upstreamrepository (von dem aus der Fork erfolgt ist) als Remoterepository namens „upstream“ hinzufügen.
git remote add upstream {upstream_url}
Vornehmen und Pushen von Änderungen
Es ist möglich, direkt im Mainbranch zu arbeiten. Schließlich ist dieser Fork Ihre Kopie des Repositorys.
Es wird jedoch empfohlen, weiterhin in einem Topic-Branch zu arbeiten.
Dadurch können Sie mehrere unabhängige Arbeitsstreams gleichzeitig verwalten.
Außerdem verringert es die Verwirrung, wenn Sie später Änderungen mit Ihrem Fork synchronisieren möchten.
Nehmen Sie Ihre Änderungen wie gewohnt vor und committen Sie sie. Wenn Sie mit den Änderungen fertig sind, pushen Sie sie in den ursprünglichen Fork (Ihren Fork).
Erstellen und Abschließen eines Pull Requests
Öffnen Sie einen Pull Request von Ihrem Fork zum Upstreamrepository. Alle Richtlinien, die für die Überprüfung und das Erstellen von Projekten erforderlich sind, werden im Upstreamrepository angewendet. Sobald alle Richtlinien erfüllt sind, kann der Pull Request abgeschlossen werden, und die Änderungen werden zu einem dauerhaften Bestandteil des Upstreamrepositorys.
Wichtig
Jeder Benutzer mit Leseberechtigung kann einen Pull Request für das Upstreamrepository öffnen. Wenn eine PR-Buildpipeline konfiguriert ist, wird der Build für den in der Fork eingeführten Code ausgeführt.
Synchronisieren Ihrer Fork auf die neueste Version
Wenn Ihr Pull Request im Upstreamrepository akzeptiert wurde, sollten Sie sicherstellen, dass Ihr Fork den aktuellen Zustand des Repositorys widerspiegelt.
Wir empfehlen, den Mainbranch des Upstreamrepositorys als neue Basis zu verwenden (vorausgesetzt, der Mainbranch ist der Hauptentwicklungsbranch).
git fetch upstream main
git rebase upstream/main
git push origin
Mit dem Forking-Workflow können Sie Änderungen vom Hauptrepository isolieren, bis Sie bereit sind, diese zu integrieren. Wenn Sie bereit sind, ist die Integration von Code so einfach wie das Abschließen eines Pull Requests.