Beschreiben der inneren Quelle mit Forks
Benutzer forken 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 würden Sie das Code-Repository ändern?
Wir suchen nach technischen Gründen, um etwas in unserer Arbeit zu verbessern.
Möglicherweise finden Sie eine bessere Möglichkeit, die 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.
- Ich denke, das Projekt ist spannend und ich möchte es vielleicht verwenden.
- Ich möchte code in diesem Repository als Ausgangspunkt für mein Projekt verwenden.
Softwareteams werden ermutigt, zu allen Projekten intern und nicht nur zu ihren Softwareprojekten beizutragen.
Forks sind eine großartige Möglichkeit, eine Kultur der inneren Open Source zu fördern.
Forks sind eine kürzliche Ergänzung zu den Git-Repositorys von Azure DevOps.
In dieser Anleitung lernen Sie, ein vorhandenes Repository zu forken und Änderungen per Pull Request zu einem Upstreamrepository beizutragen.
Vorbereiten
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.
Ein Fork kopiert nicht die Berechtigungen, Richtlinien oder Builddefinitionen des Repositories, das geforkt wird.
Nachdem ein Fork erstellt wurde, werden die neu erstellten Dateien, Ordner und Branches nicht zwischen den Repositories geteilt, es sei denn, Sie starten eine Pull-Anfrage.
Pull Requests werden in beide Richtungen unterstützt: „Fork zu Upstream“ oder „Upstream zu Fork“.
Der gängigste Ansatz für einen Pull Request ist „Fork zu Upstream“.
Vorgehensweise
Wählen Sie die Schaltfläche "Verzweigung" (1) und dann das Projekt aus, in dem die Verzweigung erstellt werden soll (2). Geben Sie Ihrer Verzweigung einen Namen, und wählen Sie die Fork-Schaltfläche (3) aus.
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. Der Einfachheit halber sollten Sie das Upstreamrepository (von dem aus der Fork erfolgt ist) als Remoterepository namens „upstream“ hinzufügen. Geben Sie in der Befehlszeile Folgendes ein:
git remote add upstream {upstream_url}Es ist möglich, direkt im Main zu arbeiten – dieser Fork ist 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 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 die Änderungen abgeschlossen haben, pushen Sie sie an den Ursprung (Ihren Fork).
Öffnen Sie einen Pull-Request von Ihrem Fork zum Upstream. 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 Bestandteil des Upstreamrepositorys
Wenn Ihr Pull Request Upstream akzeptiert wird, müssen Sie sicherstellen, dass Ihr Fork den neuesten Repositorystatus widerspiegelt. Wir empfehlen, den Mainbranch des Upstreamrepositorys als neue Basis zu verwenden (vorausgesetzt, der Mainbranch ist der Hauptentwicklungsbranch). Führen Sie in der Befehlszeile Folgendes aus:
git fetch upstream main git rebase upstream/main git push origin
Weitere Informationen zu Git finden Sie unter: