Beschreiben der inneren Quelle mit Forks
Repositorys werden geforkt, wenn die zuständigen Personen den Code in einem Repository ändern möchten, auf das sie keinen Schreibzugriff besitzen.
Wenn Sie keinen Schreibzugriff haben, sind Sie nicht Teil des Teams, das zu diesem Repository beiträgt. Warum sollten Sie also das Coderepository ändern?
Wir neigen dazu, nach technischen Gründen zu suchen, um etwas an unserer Arbeit zu verbessern.
Vielleicht finden Sie einen besseren Weg, die Lösung zu implementieren oder die Funktionalität zu verbessern, indem Sie zu einem vorhandenen Feature beitragen oder es verbessern.
Sie können Repositorys in den folgenden Situationen forken:
- Ich möchte eine Änderung vornehmen.
- Ich finde das Projekt interessant und möchte es vielleicht verwenden.
- Ich möchte einen Teil des Codes in diesem Repository als Startpunkt für mein Projekt verwenden.
Softwareteams werden ermutigt, zu allen internen Projekten beizutragen, nicht nur zu ihren eigenen Softwareprojekten.
Forks sind eine hervorragende Möglichkeit, eine Kultur der Inner-Open-Source-Nutzung zu fördern.
Forks sind eine kürzliche Ergänzung der Azure DevOps Git-Repositorys.
In dieser Anleitung lernen Sie, ein vorhandenes Repository zu forken und Änderungen per Pull Request zu einem Upstreamrepository beizutragen.
Vorbereitung
Ein Fork beginnt mit dem gesamten Inhalt des (ursprünglichen) Upstreamrepositorys.
Wenn Sie in Azure DevOps einen Fork erstellen, können Sie alle Branches einbeziehen oder ihn auf den Standardbranch beschränken.
Ein Fork kopiert nicht die Berechtigungen, Richtlinien oder Builddefinitionen des Repositorys, das geforkt wird.
Nachdem ein Fork erstellt wurde, werden die neu erstellten 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 gängigste Ansatz für einen Pull Request ist „Fork zu Upstream“.
Vorgehensweise
Klicken Sie auf die Forkschaltfläche (1), und wählen Sie dann das Projekt aus, in dem der Fork erstellt werden soll (2). Geben Sie Ihrem Fork einen Namen, und wählen Sie die Fork-Schaltfläche (3) aus.
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 das Upstreamrepository (von dem aus der Fork erfolgt ist) als Remoterepository namens „upstream“ hinzufügen. Geben Sie Folgendes an der Befehlszeile ein:
git remote add upstream {upstream_url}Es ist möglich, direkt im main-Branch zu arbeiten. Dieser Fork ist 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 die Änderungen abgeschlossen haben, pushen Sie sie an den Ursprung (Ihren Fork).
Öffnen Sie einen Pull Request von Ihrem Fork zum Upstreamrepository. 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 hier: