Beschreiben der inneren Quelle mit Forks

  • 5 Minuten

Benutzer erstellen Forks von Repositories, wenn sie den Code in einem Repository ändern möchten, auf das sie keinen Schreibzugriff haben.

Wenn Sie keinen Schreibzugriff haben, sind Sie nicht Teil des Teams, das zu diesem Repository beiträgt. Warum möchten Sie das Code-Repository ändern?

Häufige Gründe für das Forken

Wir suchen oft nach technischen Gründen, um etwas in unserer Arbeit zu verbessern. Möglicherweise finden Sie eine bessere Möglichkeit, eine Lösung zu implementieren oder Funktionen zu verbessern, indem Sie zu einem vorhandenen Feature beitragen oder verbessern.

Sie können Repositorys in den folgenden Situationen forken:

  • Ich möchte eine Änderung vornehmen: Sie haben einen Fehler gefunden oder möchten dem Projekt einer anderen Person ein Feature hinzufügen.
  • Ich denke, das Projekt ist interessant und kann es verwenden: Sie möchten mit dem Code experimentieren, ohne das Original zu beeinträchtigen.
  • Ich möchte Code als Ausgangspunkt verwenden: Sie möchten auf vorhandenen Arbeiten für Ihr eigenes Projekt aufbauen.

Softwareteams werden ermutigt, zu allen Projekten intern und nicht nur zu ihren eigenen Softwareprojekten beizutragen. Forks sind eine großartige Möglichkeit, eine Kultur der inneren Open Source zu fördern.

Azure DevOps-Forks

Forks sind in Azure DevOps Git-Repositorys verfügbar. In diesem Abschnitt erfahren Sie, wie Sie ein vorhandenes Repository forken und Änderungen über einen Pull Request upstream beitragen.

Grundlegendes zur Forkstruktur

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

Wichtige Punkte:

  • Ein Fork kopiert nicht die Berechtigungen, Richtlinien oder Builddefinitionen des Repositories, das geforkt wird.
  • Nachdem ein Fork erstellt wurde, werden neu erstellte Dateien, Ordner und Branches nicht zwischen den Repositorys freigegeben, es sei denn, Sie starten einen Pull-Request.
  • Pull Requests werden in beide Richtungen unterstützt: „Fork zu Upstream“ oder „Upstream zu Fork“.
  • Der am häufigsten verwendete Ansatz für einen Pull-Request ist vom Fork zum Upstream.

Schrittweiser Fork-Workflow

Schritt 1: Erstellen der Verzweigung

  1. Wählen Sie die Schaltfläche "Fork" (1) aus.
  2. Wählen Sie das Projekt aus, in dem die Verzweigung erstellt werden soll (2).
  3. Geben Sie Ihrer Verzweigung einen Namen, und wählen Sie die Fork-Schaltfläche (3) aus.

Schritt 2: Klonen Ihres Forks

Sobald Ihr Fork fertig ist, klonen Sie ihn über die Kommandozeile oder eine IDE, z. B. Visual Studio. Der Fork wird zu Ihrem ursprünglichen Remoterepository.

git clone {your_fork_url}
For convenience, 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: Nehmen Sie Ihre Änderungen vor

Es ist möglich, direkt im Mainbranch zu arbeiten. Dieser Fork ist Ihre Kopie des Repositorys. 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 committen Sie sie. Wenn Sie die Änderungen abgeschlossen haben, verschieben Sie sie an den Ursprung (Ihren Fork).

Schritt 4: Erstellen einer Pullanforderung

Öffnen Sie einen Pull-Request aus Ihrem Fork auf das Upstream-Repository. Das Upstreamrepository wendet alle Richtlinien an, die für Reviewer und Builds erforderlich sind. Sobald alle Richtlinien erfüllt sind, kann der Pull Request abgeschlossen werden, und die Änderungen werden zu einem dauerhaften Teil des Upstream-Repositories.

Diagramm mit

Schritt 5: Gabel synchronisieren

Wenn Ihr Pull-Request zum Ursprungsprojekt akzeptiert wird, müssen Sie sicherstellen, dass Ihr Fork den neuesten Repository-Status wiedergibt. 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 Verzweigungsworkflow bietet mehrere Vorteile:

  • Unabhängigkeit: Sie können an Änderungen arbeiten, ohne dass sich dies auf das ursprüngliche Repository auswirkt.
  • Zusammenarbeit: Mehrere Personen können zu Projekten beitragen, an den sie normalerweise nicht arbeiten.
  • Qualitätskontrolle: Alle Änderungen durchlaufen denselben Überprüfungsprozess, bevor sie zusammengeführt werden.
  • Lernen: Entwickler können code in den Projekten anderer Teams erkunden und lernen.

Weitere Informationen zu Git finden Sie unter: