Ändern des Standardbranches

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

Der Standardbranch ist der erste Branch, den Git bei einem neuen Klon auscheckt. Außerdem zielen Pull Requests standardmäßig auf diesen Branch ab.

Wir werden den Prozess zum Ändern des Standardbranchs durchgehen. Wir behandeln auch andere Dinge, die Sie berücksichtigen und aktualisieren müssen, wenn Sie diese Änderung vornehmen. Schließlich sehen wir uns ein Tool an, das den Übergang erleichtert.

Festlegen eines neuen Standardbranchs

Sie können einen anderen Branch als main für neue Änderungen verwenden oder Ihre Hauptentwicklungslinie in Ihrem Repository ändern. Informationen zum Ändern des Standardbranchnamens für neue Repositorys finden Sie unter Einstellungen und Richtlinien für alle Repositorys.

Um den Standardbranch Ihres Repositorys zum Zusammenführen neuer Pull Requests zu ändern, benötigen Sie mindestens zwei Branches. Wenn nur ein Branch vorhanden ist, ist dieser bereits der Standardbranch. Sie müssen einen zweiten Branch erstellen, um den Standardbranch zu ändern.

Es gibt weitere Aspekte, die Sie berücksichtigen sollten, bevor Sie diese Änderung vornehmen.

Wählen Sie einen Namen aus.

Mit Git 2.28 wurde die Möglichkeit hinzugefügt, einen anfänglichen Branchnamen auszuwählen. Gleichzeitig haben Azure Repos, GitHub und andere Git-Hostinganbieter die Möglichkeit hinzugefügt, einen anderen anfänglichen Branchnamen auszuwählen. Bisher hieß die Standardbranch fast immer master. Der beliebteste alternative Name ist main. Weniger häufig verwendete Optionen sind trunk und development. Wenn keine Einschränkungen für die Tools, die Sie verwenden, oder das Team, in dem Sie arbeiten, vorliegen, funktionieren alle gültigen Branchnamen.

Aktualisieren anderer Systeme

Wenn Sie zu einem anderen Standardbranch wechseln, sind möglicherweise andere Teile Ihres Workflows betroffen. Sie müssen diese Teile berücksichtigen, wenn Sie eine Änderung planen.

Pipelines

Aktualisieren Sie die CI-Trigger für alle Pipelines. Designer-Pipelines können im Web bearbeitet werden. YAML-Pipelines können in ihren jeweiligen Repositorys bearbeitet werden.

In-Flight Pull Requests

Richten Sie jeden geöffneten Pull Request auf den neuen Standardbranch als Ziel aus.

Vorhandene Klone

Neue Klone des Repositorys erhalten den neuen Standardbranch. Nach dem Wechsel sollte jeder mit einem vorhandenen Klon git remote set-head origin -a ausführen (ersetzen Sie dabei origin durch den Namen des Remoterepositorys, wenn es sich um ein anderes handelt), um seine Ansicht des Standardbranchs des Remoterepositorys zu aktualisieren. Zukünftige neue Branches sollten auf der neuen Standardeinstellung basieren.

Eingehende Links

Einige Lesezeichen, Dokumente und andere Nichtcodedateien, die auf Dateien in Azure Repos verweisen, müssen aktualisiert werden. Der Branchname für eine Datei oder ein Verzeichnis kann in der URL angezeigt werden.

Wenn eine URL eine Abfragezeichenfolge für version enthält, z. B. &version=GBmybranchname, sollte diese URL aktualisiert werden. Glücklicherweise enthalten die meisten Links zum Standardbranch kein version-Segment und können unverändert bleiben. Sobald Sie den alten Standardbranch gelöscht haben, werden Versuche, zu diesem zu navigieren, sowieso zum neuen Standardbranch umgeleitet.

Temporäre Spiegelung

Ein Git-Repository kann nur einen Standardbranch haben. Sie können jedoch für einen gewissen Zeitraum Ad-hoc-Spiegelung zwischen Ihrem alten Standardbranch und dem neuen Standardbranch einrichten. Auf diese Weise müssen Ihre Endbenutzer die Arbeit nicht wiederholen, wenn sie weiterhin in den alten Standardbranch pushen. Wir verwenden Azure Pipelines, um diese temporäre Spiegelung einzurichten.

Die Spiegelungspipeline

1. Aktualisieren Sie für alle vorhandenen CI-Builds diese so, dass sie für Ihren neuen Standardbranch ausgelöst werden, anstatt für den alten.

2. Erteilen Sie der Buildidentität die Berechtigung Mitwirken für Ihr Repository. Navigieren Sie zu Projekteinstellungen>Repositorys>(Ihr Repository)>Berechtigungen. Es können bis zu zwei Identitäten vorhanden sein: eine für den Projektsammlungs-Builddienst und die andere für den Projektbuilddienst. Stellen Sie sicher, dass die Berechtigung „Mitwirken“ auf Allow (Zulassen) festgelegt ist.

3. Wenn der neue Standardbranch über Branchrichtlinien verfügt, erteilen Sie der Buildidentität außerdem die Berechtigung Richtlinien bei Pushvorgängen umgehen. Diese Berechtigung stellt ein Sicherheitsrisiko dar, da ein böswilliger Benutzer eine Pipeline erstellen könnte, um Code in ein Repository in Ihrem Projekt einzuschleusen. Wenn die Spiegelung nicht mehr benötigt wird, stellen Sie sicher, dass Sie diese Berechtigung entfernen.

4. Fügen Sie Ihrem Repository im neuen Standardbranch eine neue Datei mirror.yml hinzu. In diesem Beispiel wird davon ausgegangen, dass der alte Standardbranch master war und der neue main ist. Aktualisieren Sie die auslösenden Branches und die git push-Zeile, wenn sich Ihre Branchnamen unterscheiden.

trigger:
  branches:
    include:
    - main
    - master
 
pool: { vmImage: ubuntu-latest }
steps:
- checkout: self
  persistCredentials: true
- script: |
    git checkout $(Build.SourceBranchName)
    git push origin HEAD:master HEAD:main
  displayName: Mirror old and new default branches

5. Erstellen Sie eine neue Pipeline, und wählen Sie dabei im Assistenten „Azure Repos Git“ und „Vorhandene Azure Pipelines YAML-Datei“ aus. Wählen Sie die mirror.yml-Datei aus, die Sie im vorherigen Schritt hinzugefügt haben. Speichern Sie die Pipeline, und führen Sie sie aus.

Problembehandlung

Diese Pipeline wird jedes Mal ausgeführt, wenn ein Push in master oder in main erfolgt. Sie hält die Branches synchronisiert, solange keine neuen Commits gleichzeitig in beiden Branches eingehen.

Wenn die Pipeline mit einer Fehlermeldung wie „Updates wurden abgelehnt, weil eine gepushte Branchspitze hinter der Remoteversion zurückliegt“ fehlschlägt, muss jemand den alten Branch manuell in den neuen Branch zusammenführen.

1. Klonen Sie das Repository und cd in das zugehörige Verzeichnis.
2. Checken Sie den neuen Standardbranch mit git checkout main aus (falls main Ihr neuer Standardbranch ist).
3. Erstellen Sie einen neuen Branch zum Integrieren der zwei Branches in git checkout -b integrate.
4. Führen Sie den alten Standardbranch mit git merge master (falls master Ihr alter Standardbranch ist).
5. Pushen Sie den neuen Branch, öffnen Sie einen Pull Request in den neuen Standardbranch, und schließen Sie diesen ab.
6. Die Spiegelungspipeline sollte dann dafür sorgen, dass der Mergecommit wieder in den alten Standardbranch gespiegelt wird.