Implementieren des Fork-Workflows
Eine Verzweigung ist eine Kopie eines Repositories. Durch das Forken eines Repositorys können Sie mit Änderungen experimentieren, ohne das ursprüngliche Projekt zu beeinflussen.
Am häufigsten werden Forks verwendet, um Änderungen am Projekt einer anderen Person vorzuschlagen. Oder verwenden Sie das Projekt einer anderen Person als Ausgangspunkt für Ihre Idee.
Ein Fork ist eine vollständige Kopie eines Repositories, einschließlich aller Dateien, Commits und (optional) Verzweigungen.
Forks sind eine hervorragende Möglichkeit, einen Inner-Source-Workflow zu unterstützen: Sie können eine Gabelung erstellen, um Änderungen vorzuschlagen, wenn Sie keine Berechtigung haben, direkt in das ursprüngliche Projekt zu schreiben.
Sobald Sie bereit sind, diese Änderungen freizugeben, ist es einfach, sie mithilfe von Pullanforderungen wiederzuverwenden.
Was ist in einer Gabel?
Eine Abzweigung beginnt mit allen Inhalten des ursprünglichen (upstream) Repositories.
Sie können alle Verzweigungen einschließen oder sie nur auf die Standardverzweigung beschränken, wenn Sie eine Verzweigung erstellen.
Keine der Berechtigungen, Richtlinien oder Build-Pipelines wird angewendet.
Die neue Fork verhält sich so, als hätte jemand das ursprüngliche Repository geklont und es dann in ein neues, leeres Repository gepusht.
Nachdem ein Fork erstellt wurde, werden neue Dateien, Ordner und Branches nicht zwischen den Repositories freigegeben, es sei denn, eine Pull-Anforderung (PR) überträgt sie.
Austausch von Code zwischen Forks
Sie können PRs in eine der beiden Richtungen erstellen: von einer Verzweigung zum Upstream oder vom Upstream zur Verzweigung.
Der häufigste Ansatz ist es, vom Fork zum Upstream zu gehen.
Die Berechtigungen, Richtlinien, Builds und Arbeitsaufgaben des Ziel-Repositorys gelten für die PR.
Auswählen zwischen Zweigen und Abzweigungen
Für ein kleines Team (2-5 Entwickler) empfehlen wir, in einem einzelnen Repository zu arbeiten.
Jeder sollte in einem Feature-Branch arbeiten, und der Main-Branch sollte durch Branch-Richtlinien geschützt werden.
Wenn Ihr Team größer wird, können Sie feststellen, dass Sie diese Anordnung überflügeln und lieber zu einem Forking-Workflow wechseln möchten.
Wir empfehlen den Fork-Workflow, wenn Ihr Repository viele gelegentliche oder seltene Beiträge hat (z. B. bei einem Open-Source-Projekt).
In der Regel verfügen nur Kernmitwirkende für Ihr Projekt über direkte Commitrechte in Ihr Repository.
Es wäre hilfreich, wenn Sie Mitarbeiter von außerhalb des Kernteams bitten, aus einem Fork des Repositorys zu arbeiten.
Außerdem werden Ihre Änderungen von Ihren eigenen getrennt, bis Sie die Gelegenheit hatten, die Arbeit zu überprüfen.
Der Verzweigungs-Workflow
- Erstellen Sie einen Fork.
- Klonen Sie es lokal.
- Nehmen Sie Ihre Änderungen lokal vor, und laden Sie sie dann auf einen Branch hoch.
- Erstellen und Abschließen einer PR für upstream.
- Aktualisieren Sie Ihren Fork mit dem Neuesten von Upstream.
Verzweigung erstellen
- Navigieren Sie zum Repository, um einen Fork zu erstellen, und wählen Sie "Fork" aus.
- Geben Sie einen Namen an, und wählen Sie das Projekt aus, in dem die Verzweigung erstellt werden soll. Wenn das Repository viele Themenverzweigungen enthält, wird empfohlen, nur die Standardverzweigung zu verzweigen.
- Wählen Sie die Auslassungspunkte und dann "Verzweigung" aus, um die Verzweigung zu erstellen.
Anmerkung
Sie müssen über die Berechtigung "Repository erstellen" in Ihrem ausgewählten Projekt verfügen, um eine Verzweigung zu erstellen. Es wird empfohlen, ein dediziertes Projekt für Forks zu erstellen, bei denen alle Mitwirkenden über die Berechtigung "Repository erstellen" verfügen. Ein Beispiel für die Erteilung dieser Berechtigung finden Sie unter "Festlegen von Git-Repositoryberechtigungen".
Klonen Sie Ihren Fork lokal.
Sobald Ihr Fork bereit ist, klonen Sie ihn mithilfe der Befehlszeile oder einer IDE wie Visual Studio. Der Fork wird Ihr origin-Remote sein.
Zur Vereinfachung sollten Sie nach dem Klonen das Upstream-Repository (wo Sie es abgezweigt haben) als Remote namens upstream hinzufügen.
git remote add upstream {upstream_url}
Änderungen vornehmen und pushen
Es ist möglich, direkt in main zu arbeiten - schließlich ist dieser Fork Ihre Kopie des Repositories.
Es wird jedoch empfohlen, dass Sie weiterhin in einem Themenzweig arbeiten.
Sie können mehrere unabhängige Arbeitsabläufe gleichzeitig verwalten.
Außerdem wird die Verwirrung später reduziert, wenn Sie Änderungen mit Ihrem Fork synchronisieren möchten.
Nehmen Sie Ihre Änderungen wie gewohnt vor, und übernehmen Sie sie. Wenn Sie mit den Änderungen fertig sind, pushen Sie sie auf den origin (Ihren Fork).
PR erstellen und abschließen
Öffnen Sie eine Pull-Anforderung von Ihrer Verzweigung bis zum Upstream. Alle für Prüfer und Builds notwendigen Richtlinien werden im Upstream-Repository angewendet. Sobald alle Richtlinien erfüllt sind, kann die PR abgeschlossen werden, und die Änderungen werden zu einem dauerhaften Teil des Upstream-Repositorys.
Wichtig
Jeder mit Leseberechtigung kann eine PR an das Upstream-Repository öffnen. Wenn eine PR-Buildpipeline konfiguriert ist, wird der Build gegen den in der Verzweigung eingeführten Code ausgeführt.
Ihre Fork auf den neuesten Stand bringen
Wenn Ihr Pull Request in den Upstream integriert wurde, sollten Sie sicherstellen, dass Ihr Fork den neuesten Stand des Repositories widerspiegelt.
Wir empfehlen, auf den Hauptzweig des Upstreams zu wechseln (vorausgesetzt, „main“ ist der Hauptentwicklungszweig).
git fetch upstream main
git rebase upstream/main
git push origin
Der Forking-Workflow ermöglicht es Ihnen, Änderungen aus dem Haupt-Repository zu isolieren, bis Sie bereit sind, sie zu integrieren. Wenn Sie bereit sind, ist die Integration von Code so einfach wie das Abschließen einer Pullanforderung.