Freigeben über

Radgabeln

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Git-Repository-Forks sind hilfreich, wenn Benutzer experimentelle, riskante oder vertrauliche Änderungen an einer Codebasis vornehmen möchten, aber diese Änderungen von der Codebasis im ursprünglichen Repository isoliert werden müssen. Ein neuer Fork ist im Grunde ein neues Remote-Repository, das den Quellcode des ursprünglichen Repositorys freigibt.

Als unabhängige Version werden Änderungen, die Sie an Ihrem Fork vornehmen, z. B. das Hinzufügen von Commits oder Branches, vor dem ursprünglichen Repository versteckt. Wenn Sie Ihre Codebasisänderungen im ursprünglichen Repository zusammenführen möchten, müssen Sie einen Pull Request (PR) erstellen, um die Überprüfung und Genehmigung dieser Änderungen anzufordern.

Im Rahmen des Forkingprozesses werden keine Berechtigungen, Richtlinien oder Buildpipelines vom ursprünglichen Repository an Ihren Fork übertragen.

Dieser Artikel behandelt die Arbeit mit Forks in Azure Repos Git-Repositorys und enthält Links zu GitHub-Inhalten, in denen erläutert wird, wie Forks in GitHub-Repositorys verwaltet werden.

In diesem Artikel wird Folgendes behandelt:

  • Freigeben von Code zwischen Forks
  • Auswählen zwischen Branches und Forks
  • Aktivieren von Repository-Forks
  • Erstellen eines Forks
  • Lokales Klonen des Forks
  • Pushen lokaler Änderungen an Ihren Fork
  • Erstellen und Abschließen eines Pull Requests
  • Synchronisieren Ihres Forks

Voraussetzungen für den Zugriff auf Azure Repos

  • Repositorys müssen in Ihren Azure DevOps-Projekteinstellungen aktiviert sein. Wenn der Repository-Hub und die zugehörigen Seiten nicht angezeigt werden, lesen Sie Aktivieren oder Deaktivieren eines Azure DevOps-Diensts, um Repos neu zu aktivieren.

  • Um Code in privaten Projekten anzuzeigen, müssen Sie Mitglied eines Azure DevOps-Projekts mit der Zugriffsebene Basic oder höher sein. Bei öffentlichen Projekte kann jeder den Code anzeigen.

  • Um Code für ein privates Projekt zu klonen oder daran mitzuwirken, müssen Sie Mitglied der Sicherheitsgruppe Mitwirkende sein oder es müssen die entsprechenden Berechtigungen für Sie festgelegt worden sein. Bei öffentlichen Projekten kann jeder Code klonen und mitwirken. Weitere Informationen finden Sie unter Was ist ein öffentliches Projekt?.

    Hinweis

    Bei öffentlichen Projekten haben Benutzer, denen Zugriff für Interessengruppen eingeräumt wurde, vollen Zugriff auf Azure Repos.

  • Repositorys müssen in Ihren Azure DevOps-Projekteinstellungen aktiviert sein. Wenn der Repository-Hub und die zugehörigen Seiten nicht angezeigt werden, lesen Sie Aktivieren oder Deaktivieren eines Azure DevOps-Diensts, um Repos neu zu aktivieren.

  • Um Code anzuzeigen, müssen Sie Mitglied des Azure DevOps-Projekts mit Zugriff der Ebene Basic oder höher sein. Wenn Sie kein Projektmitglied sind, lassen Sie sich hinzufügen.

  • Um Code zu klonen oder daran mitzuwirken, müssen Sie Mitglied der Sicherheitsgruppe Mitwirkende sein oder für das Projekt, das Sie ändern möchten, über die entsprechenden Berechtigungen verfügen.

Freigeben von Code zwischen Forks

Das ursprüngliche Repository wird häufig als Upstream-Repository bezeichnet. Sie können Pull Requests zum Zusammenführen von Änderungen für beide Richtungen erstellen: „Fork zu Upstream“ oder „Upstream zu Fork“. Die gebräuchlichste Richtung ist von Fork zu Upstream. Die Berechtigungen, Richtlinien, Builds und Arbeitselemente des Zielrepositorys gelten für den PR.

Auswählen zwischen Branches und Forks

Für ein kleines Team von 2 bis 5 Entwicklern ist ein Forkingworkflow möglicherweise nicht erforderlich, da jeder in Featurebranches arbeiten kann und Branchrichtlinien den Standardbranch schützen können. Wenn Ihr Team diese Anordnung jedoch erweitert und zu groß für sie wird, kann es zu einem Forkingworkflow wechseln.

Wenn Ihr Repository eine große Anzahl von gelegentlichen oder seltenen Committern aufweist, wie es z. B. bei einm Open Source-Projektd der Fall sein kann, empfehlen wir den Forkingworkflow. In der Regel haben nur die Hauptmitwirkenden an Ihrem Projekt direkte Commit-Rechte in Ihrem Repository. Andere Projektmitarbeiter sollten einen Forkingworkflow verwenden, um ihre vorgeschlagenen Änderungen zu isolieren, bis die Hauptmitwirkenden die Möglichkeit haben, ihre Arbeit zu überprüfen.

Aktivieren von Repository-Forks

Informationen zum Aktivieren von Forks für ein Azure Repos Git-Repository finden Sie unter Aktivieren von Forks.

Informationen zum Aktivieren von Forks für ein GitHub-Repository finden Sie unter Verwalten der Forkingrichtlinie für Ihre Organisation.

Forking-Workflow

Der Forkingworkflow besteht aus fünf Schritten, die in den folgenden Abschnitten beschrieben werden.

  1. Erstellen eines Forks
  2. Lokales Klonen des Forks
  3. Pushen lokaler Änderungen an Ihren Fork
  4. Erstellen und Abschließen eines Pull Requests
  5. Synchronisieren Ihres Forks

Erstellen eines Forks

In den folgenden Schritten wird beschrieben, wie Sie ein Azure Repos Git-Repository forken.

Hinweis

Um ein Repository in einem Azure DevOps-Projekt zu forken, benötigen Sie die Berechtigung Repository erstellen für dieses Projekt. Repositorybesitzer sollten erwägen, ein eigenes Projekt für Forks zu erstellen und allen Mitwirkenden die Berechtigung zum Ersellen von Repositorys zuzuweisen. Weitere Informationen zum Festlegen von Berechtigungen finden Sie unter Festlegen von Git-Repositoryberechtigungen.

  1. Navigieren Sie in Ihrem Webbrowser zu dem Azure Repos Git-Repository, das Sie forken möchten. Wählen Sie Repository > Dateien und dann im Menü mit den Auslassungspunkten die Option Fork aus, um das Dialogfeld Fork zu öffnen.

    Screenshot des Menüelements „Fork“ im Menü „Weitere Aktionen“ auf der Seite „Repositorydateien“ in Azure Repos.

  2. Benennen Sie im Dialogfeld Fork das geforkte Repository und wählen Sie das Projekt, in dem der Fork erstellt werden soll, die Branches, die in den Fork eingeschlossen werden sollen, und anschließend Fork aus. Sie können angeben, ob der Fork alle Branches oder nur den Standardbranch enthalten soll. Wenn das Repository mehrere Themenbranches enthält, sollten Sie nur den Standardbranch in Ihren Fork einschließen.

    Screenshot des Dialogfelds „Fork“ auf der Seite „Repositorydateien“ in Azure Repos.

Informationen zum Forken eines GitHub-Repositorys finden Sie unter Forken eines Repositorys.

Lokales Klonen des Forks

Nachdem Sie ein Repository geforkt haben, klonen Sie Ihren Fork, um eine lokale Kopie in einem Ordner auf Ihrem Computer zu erstellen. Sie können über die Befehlszeile oder mithilfe einer IDE wie Visual Studio klonen. Weitere Informationen zum Klonen eines Repositorys finden Sie unter Klonen eines vorhandenen Git-Repositorys.

Wenn Sie ein Remoterepository klonen, weist Git den Alias origin als Kürzel für die URL des geklonten Remoterepositorys zu. Fügen Sie der Einfachheit halber einen weiteren Alias namens upstream zu dem Repository hinzu, in dem Sie den Forkingvorgang durchgeführt haben und das als Upstreamrepository bezeichnet wird. Die folgenden Schritte beschreiben, wie ein upstream-Alias hinzugefügt wird.

Tipp

Der Einfachheit halber können Sie den origin- und upstream-Alias anstelle der entsprechenden URLs in Ihren Git-Befehlen verwenden.

Führen Sie die folgenden Schritte aus, um einen upstream-Alias in Visual Studio hinzuzufügen:

  1. Wählen Sie in der Menüleiste Extras > Optionen aus, um das Fenster Optionen zu öffnen. Wählen Sie Quellcodeverwaltung > Git-Repositoryeinstellungen > Remotes und dann Hinzufügen aus, um das Dialogfeld Remote hinzufügen zu öffnen.

    Screenshot: Schaltfläche „Hinzufügen“ im Bereich „Remotes“ des Untermenüs „Git Repository-Einstellungen“ im Menü „Quellcodeverwaltung“ in Visual Studio 2019.

  2. Fügen Sie im Dialogfeld Remote hinzufügen ein neues Remoterepository namens upstream hinzu, und geben Sie die Git-Klon-URL des Repositorys ein, das Sie geforkt haben. Wählen Sie dann Speichern aus.

    Screenshot des Dialogfelds „Remote hinzufügen“ in Visual Studio 2019.

Pushen lokaler Änderungen an Ihren Fork

Wenn Sie verzweigen, erstellen Sie eine persönliche Version des ursprünglichen Repositorys (ursprüngliches Repository wird als „upstream“ bezeichnet). Die Verzweigung ist unabhängig vom Upstream. Der Fork teilt jedoch den Code und hält eine Verbindung zum Upstream aufrecht, sodass die zukünftige Synchronisierung möglich ist. Es gibt also nichts, was Sie daran hindert, direkt im main-Branch des lokalen Klons zu arbeiten und diese Arbeit dann in den main-Branch Ihres Forks zu pushen. Im Allgemeinen ist es jedoch besser, Feature-Branches für Ihre Arbeit zu verwenden. Mithilfe von Featurebranches:

  • Sie können mehrere unabhängige Workstreams gleichzeitig verwalten.

  • Sie erleichtern es anderen, die Arbeit zu verstehen, die Sie teilen, da diese Arbeit in unterschiedlichen Arbeitsstreams nach Branch organisiert ist.

Ein typischer Git-Workflow umfasst die folgenden Schritte:

  1. Erstellen Sie ein lokales Feature oder einen Bugfixbranch.

  2. Nehmen Sie Änderungen an dem neuen Branch vor, und committen Sie Ihre Arbeit. In der Regel nehmen Personen mehrere Commits vor, wenn sie an einem Feature oder einer Fehlerbehebung arbeiten.

  3. Pushen Sie das Feature oder den Fehlerbehebungsbranch in Ihren Fork. Ihr Fork hat den Alias origin.

Informationen zum Pushen Ihrer Änderungen finden Sie unter Freigeben eines Code mithilfe von Push.

Erstellen und Abschließen eines Pull Requests

In Azure Repos können Sie, um die Änderungen, die Sie in Ihren Fork gepusht haben, in das ursprüngliche Repository zusammenzuführen:

  1. Einen PR erstellen, um den Review und die Genehmigung Ihrer Änderungen anzufordern. Wenn Sie einen PR öffnen, legen Sie den PR-Quellbranch auf den Feature- oder Bugfixbranch in Ihrem Fork fest. Der PR-Zielbranch ist in der Regel der main Branch des Repositorys, das Sie geforkt haben. Dieses Repository wird als Upstream-Repository bezeichnet und hat den Alias upstream.

    Der folgende Screenshot zeigt das Quell-Repository und den Branch sowie das Ziel-Repository und den Branch eines in Azure Repos erstellten PR.

    Screenshot der PR-Quell- und Zielbranchoptionen in Azure Repos.

    Weitere Informationen zum Erstellen eines PR in Ihrem Browser, Visual Studio oder der Azure DevOps CLI finden Sie unter Erstellen eines PR.

    Wichtig

    Jeder mit Leseberechtigung für das Upstream-Repository kann einen PR öffnen. Wenn das Upstream-Repositorys über eine PR-Build-Pipeline verfügt, die für die Ausführung bei der PR-Erstellung konfiguriert ist, wird ein Build für die von Ihrem PR eingeführten Änderungen ausgeführt.

  2. Damit Ihr PR abgeschlossen ist, müssen alle erforderlichen Reviewer die PR-Änderungen genehmigen, und alle Zielbranchrichtlinien müssen erfüllt sein. Nach der PR-Genehmigung und dem Abschluss werden die Änderungen im PR-Quellbranch in den PR-Zielbranch zusammengeführt.

Informationen zum Erstellen und Abschließen eines GitHub-PR finden Sie unter Erstellen eines Pull Requests und Zusammenführen eines Pull Requests.

Synchronisieren Ihres Forks

Nachdem die Änderungen aus Ihrem Fork mit einem PR in den Zielbranch des Upstream Repositorys zusammengeführt worden sind, können Sie aus dem Zielbranch des Upstream-Repositorys pullen, um den entsprechenden lokalen Branch sowohl mit Ihren Änderungen als auch mit allen von anderen Mitwirkenden vorgenommenen Änderungen zu aktualisieren. Jetzt können Sie Folgendes tun:

  • Ein neues Feature oder einen Bugfixbranch aus dem aktualisierten lokalen Branch erstellen.

  • Ihren Fork aktualisieren, indem Sie von Ihrem aktualisierten lokalen Branch in originpushen.

In der Regel ist main der Zielbranch des Upstream Repositorys. Wenn Sie Ihren lokalen main-Branch nicht direkt bearbeiten (Sie arbeiten in Feature-Branches), wird durch Pullen aus dem Upstreambranch upstream/main der lokale main-Branch ohne Mergekonflikte aktualisiert.

Nächste Schritte

Freigeben eines Codes mithilfe von PushPrüfen von Pull Requests