Implementieren des Fork-Workflows

Ein „Fork“ ist eine Kopie eines Repositorys. Wenn Sie ein Repository erstellen, können Sie frei mit Änderungen experimentieren, ohne das ursprüngliche Projekt zu beeinträchtigen.

Am häufigsten werden Forks verwendet, um Änderungen am Projekt einer anderen Person vorzuschlagen oder das Projekt einer anderen Person als Ausgangspunkt für Ihre Idee zu verwenden.

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 zu teilen, ist es einfach, sie mithilfe von Pull Requests zurückzuspielen.

Was befindet sich in einem Fork?

Ein Fork beginnt mit dem gesamten Inhalt des (ursprünglichen) Upstreamrepositorys. Sie können alle Verzweigungen einschließen oder sie nur auf die Standardverzweigung beschränken, wenn Sie eine Verzweigung erstellen.

Wichtige Hinweise:

• Keine der Berechtigungen, Richtlinien oder Buildpipelines wird kopiert.
• 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 geteilt, es sei denn, ein Pull-Request trägt sie mit sich.

Freigeben von Code zwischen Forks

Sie können Pull-Anfragen in beide Richtungen erstellen: vom Fork zum Upstream oder vom Upstream zum Fork. Der am häufigsten verwendete Ansatz ist vom Fork zum Upstream.

Die Berechtigungen, Richtlinien, Builds und Arbeitsaufgaben des Ziel-Repositorys gelten für den Pull-Request.

Auswählen zwischen Branches und Forks

• Kleine Teams (2-5 Entwickler): Wir empfehlen, in einem einzigen Repository zu arbeiten. Alle sollten in einem Topic-Branch arbeiten, und der Mainbranch sollte durch Branchrichtlinien geschützt werden.

• Größere Teams: Wenn Ihr Team größer wird, kann es sein, dass dieses Arrangement nicht mehr zu Ihnen passt, und Sie ziehen es vor, zu einem Forking-Workflow zu wechseln.

• Wann man Forks verwenden sollte:

  • Ihr Repository verfügt über viele zufällige oder seltene Mitwirkende (z. B. ein Open-Source-Projekt).
  • Nur Kernmitwirkende verfügen über direkte Commit-Rechte in Ihrem Repository.
  • Sie möchten, dass Kollaboratoren außerhalb des Kernteams von einem Fork aus arbeiten.
  • Sie sollten Änderungen isolieren, bis Sie die Möglichkeit hatten, die Arbeit zu überprüfen.

Forking-Workflow

Hier sind die grundlegenden Schritte für den Forking-Workflow:

1. Erstellen Sie einen Fork.
2. Klonen Sie es lokal.
3. Nehmen Sie Ihre Änderungen lokal vor, und pushen Sie sie in einen Branch.
4. Einen Pull-Request für das Upstream-Projekt erstellen und abschließen.
5. Synchronisieren Sie Ihren Fork mit dem neuesten Stand von der Upstreamposition.

Schritt 1: Erstellen der Verzweigung

1. Navigieren Sie zu dem Repository, das Sie forken möchten, und wählen Sie "Fork" aus.
2. Geben Sie einen Namen an, und wählen Sie das Projekt aus, in dem die Verzweigung erstellt werden soll.
3. Wenn das Repository viele Topic-Branches enthält, empfehlen wir, nur den Standardbranch zu forken.
4. Wählen Sie die Auslassungspunkte und dann „Fork“ aus, um den Fork zu erstellen.

Schritt 2: 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 zu Ihrem ursprünglichen Remoterepository.

git clone {your_fork_url}
For convenience, after cloning, you'll want to add the upstream repository (where you forked from) as a remote named upstream:

```bash
git remote add upstream {upstream_url}

Schritt 3: Vornehmen und Pushen von Änderungen

Es ist möglich, direkt in main zu arbeiten - schließlich ist dieser Fork Ihre Kopie des Repositories. Es wird jedoch empfohlen, weiterhin in einem Themenzweig zu arbeiten, da:

• Sie können mehrere unabhängige Arbeitsabläufe gleichzeitig verwalten.
• Es reduziert später Verwirrung, wenn Sie Änderungen in Ihren Fork synchronisieren möchten.

Nehmen Sie Ihre Änderungen wie gewohnt vor und bestätigen Sie sie. Wenn Sie mit den Änderungen fertig sind, pushen Sie sie in den ursprünglichen Fork (Ihren Fork).

Schritt 4: Erstellen und Abschließen einer Pullanforderung

Öffnen Sie einen Pull-Request aus Ihrem Fork auf das Upstream-Repository. 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 die Pullanforderung abgeschlossen werden, und die Änderungen werden zu einem dauerhaften Teil des Upstream-Repositorys.

Schritt 5: Synchronisieren Ihres Forks mit dem aktuellen Stand

Wenn Ihre Pull-Anforderung im Upstream akzeptiert wird, sollten Sie sicherstellen, dass Ihr Fork den neuesten Stand 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

Vorteile des Fork-Workflows

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.

Dieser Ansatz bietet Folgendes:

• Sicherheit: Änderungen werden bis zur Überprüfung isoliert.
• Zusammenarbeit: Mehrere Personen können gleichzeitig an verschiedenen Features arbeiten.
• Qualität: Alle Änderungen durchlaufen denselben Überprüfungsprozess.
• Flexibilität: Mitwirkende benötigen keinen Schreibzugriff auf das Haupt-Repository.