Radgabeln

  • Artikel
  • 8 Minuten Lesedauer

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

Visual Studio 2019 | Visual Studio 2022

Git-Repository-Forks sind nützlich, wenn Benutzer experimentelle, riskante oder vertrauliche Änderungen an einer Codebasis vornehmen möchten, diese Änderungen jedoch von der Codebasis im ursprünglichen Repository isoliert werden müssen. Ein neuer Fork ist im Grunde ein Klon des ursprünglichen Repositorys, das in ein neues Remoterepository gepusht wird. Der Fork ist unabhängig vom ursprünglichen Repository und eine vollständige Kopie, es sei denn, Sie geben einen einzelnen Branch an.

Als unabhängige Kopie werden Änderungen, die Sie an Ihrem Fork vornehmen, z. B. das Hinzufügen von Commits oder Branches, nicht für das ursprüngliche Repository freigegeben. 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.

Der Forkingprozess überträgt keine Berechtigungen, Richtlinien oder Buildpipelines vom ursprünglichen Repository an Ihren Fork.

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 wiederzuverwenden.

  • Um Code in privaten Projekten anzuzeigen, müssen Sie Mitglied eines Azure DevOps-Projekts mit der Zugriffsebene Basic oder höher sein. Bei öffentlichen Projekten 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 die entsprechenden Berechtigungen festgelegt haben. 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 Interessengruppen Zugriff auf Azure Repos gewährt haben, Vollzugriff.

  • 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 wiederzuverwenden.

  • Um Code anzuzeigen, müssen Sie Mitglied des Azure DevOps-Projekts mit Basic-Zugriff oder höher sein. Wenn Sie kein Projektmitglied sind, werden Sie hinzugefügt.

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

  • Um Code anzuzeigen, müssen Sie Mitglied eines Azure DevOps-Projekts mit Basic-Zugriff oder höher sein. Wenn Sie kein Projektmitglied sind, werden Sie hinzugefügt.

  • Um Code zu klonen oder daran mitzuwirken, müssen Sie Mitglied der Sicherheitsgruppe Mitwirkende sein oder über die entsprechenden Berechtigungen verfügen.

Freigeben von Code zwischen Forks

Das ursprüngliche Repository wird häufig als Upstreamrepository bezeichnet. Sie können PRs erstellen, um Änderungen in beide Richtungen zusammenzuführen: von 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 Forking-Workflow möglicherweise nicht erforderlich, da jeder in Featureverzweigungen arbeiten kann und Branchrichtlinien den Standardbranch schützen können. Wenn Ihr Team diese Anordnung jedoch erweitert und überwächst, kann es zu einem Forking-Workflow wechseln.

Wenn Ihr Repository eine große Anzahl von gelegentlichen oder seltenen Committern aufweist, z. B. ein Open Source Projekt, empfehlen wir den Forkingworkflow. In der Regel sollten nur Hauptmitwirkende an Ihrem Projekt über direkte Commitrechte für Ihr ursprüngliches Repository verfügen. 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 dediziertes Projekt für Forks zu erstellen und allen Mitwirkenden die Berechtigung Repository erstellen zuzuweisen. Weitere Informationen zum Festlegen von Berechtigungen finden Sie unter Festlegen von Git-Repositoryberechtigungen.

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

    Screenshot des Menüelements

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

    Screenshot des Dialogfelds

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

Lokales Klonen des Forks

Nachdem Sie ein Repository gezweigt 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 Abkürzung für die URL des von Ihnen geklonten Remoterepositorys zu. Fügen Sie der Einfachheit halber einen weiteren Alias mit dem Namen upstream für das Repository hinzu, aus dem Sie gezweigt haben, der als Upstreamrepository bezeichnet wird. In den folgenden Schritten wird beschrieben, wie Ein upstream Alias hinzugefügt wird.

Tipp

Zur Vereinfachung können Sie die origin Aliase und upstream 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 der Schaltfläche

  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 gezweigt haben. Wählen Sie dann Speichern aus.

    Screenshot des Dialogfelds

Pushen lokaler Änderungen an Ihren Fork

Wenn Sie sich verzweigen, erstellen Sie eine persönliche und unabhängige Kopie des Remoterepositorys. Es gibt also nichts, was Sie daran hindern kann, direkt im main Branch des lokalen Klons zu arbeiten und diese Arbeit dann an den main Branch Ihres Forks zu pushen. Es ist jedoch im Allgemeinen besser, Feature-Branches für Ihre Arbeit zu verwenden. Mithilfe von Feature-Branches:

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

  • Sie erleichtern es anderen, die von Ihnen freigegebene Arbeit zu verstehen, da diese Arbeit in verschiedenen Arbeitsströmen nach Verzweigung organisiert ist.

Ein typischer Git-Workflow umfasst die folgenden Schritte:

  1. Erstellen Sie ein lokales Feature oder einen Fehlerbehebungsbranch.

  2. Nehmen Sie Änderungen am neuen Branch vor, und commiten Sie Ihre Arbeit. In der Regel führen Benutzer mehrere Commits durch, wenn sie an einem Feature oder einer Fehlerbehebung arbeiten.

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

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

Erstellen und Abschließen eines Pull Requests

Um die Änderungen, die Sie an Ihren Fork übertragen haben, in das ursprüngliche Repository zu integrieren, können Sie in Azure Repos:

  1. Erstellen Sie einen PR , um die Überprüfung und Genehmigung Ihrer Änderungen anzufordern. Wenn Sie einen PR öffnen, legen Sie den PR-Quellbranch auf den Feature- oder Bugfix-Branch in Ihrem Fork fest. Der PR-Zielbranch ist in der Regel der main Branch des Repositorys, das Sie gezweigt haben. Dieses Repository wird als Upstreamrepository bezeichnet und hat den Alias upstream.

    Der folgende Screenshot zeigt das Quellrepository und den Branch sowie das Zielrepository und den Branch eines PR, der in Azure Repos erstellt wurde.

    Screenshot der Optionen für pr-Quelle und Zielbranch in Azure Repos

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

    Wichtig

    Jeder, der die Berechtigung Lesen für das Upstreamrepository besitzt, kann einen PR öffnen. Wenn das Upstreamrepository über eine PR-Buildpipeline 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 werden kann, müssen alle erforderlichen Prüfer die PR-Änderungen genehmigen, und alle Zielzweigrichtlinien müssen erfüllt sein. Nach der PR-Genehmigung und -Vervollständigung 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 Request und Zusammenführen eines Pull Requests.

Synchronisieren Des Forks

Nachdem ein PR die Änderungen von Ihrem Fork mit dem Zielbranch des Upstreamrepos zusammengeführt hat, können Sie aus dem Zielbranch des Upstreamrepositorys ziehen , um Ihren entsprechenden lokalen Branch sowohl mit Ihren Änderungen als auch mit allen Änderungen zu aktualisieren, die von anderen Mitwirkenden vorgenommen wurden. Dann sind Sie bereit für:

  • Erstellen Sie ein neues Feature oder einen Fehlerbehebungsbranch aus dem aktualisierten lokalen Branch.

  • Aktualisieren Sie Ihren Fork, indem Sie von Ihrem aktualisierten lokalen Branch nachoriginpushen.

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

Nächste Schritte

Freigeben von Code mit Push pullrequests überprüfen