Standardzweig ändern

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

Die Standardbranch ist der erste Branch, den Git bei einem neuen Klon auscheckt. Außerdem zielen Pullanforderungen standardmäßig auf diese Verzweigung 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 zur Beschleunigung des Übergangs an.

Voraussetzungen

Festlegen einer neuen Standardverzweigung

Sie können einen anderen Zweig als main für neue Änderungen verwenden oder Ihre Hauptentwicklungslinie in Ihrem Repository ändern. Informationen zum Ändern des Standardverzweigungsnamens für neue Repositorys finden Sie unter "Alle Repositoryeinstellungen und -richtlinien".

Zum Ändern der Standardverzweigung Ihres Repositorys zum Zusammenführen neuer Pullanforderungen benötigen Sie mindestens zwei Verzweigungen. Wenn nur ein Branch vorhanden ist, ist dieser bereits der Standardbranch. Sie müssen eine zweite Verzweigung erstellen, um die Standardeinstellung zu ändern.

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

Wählen Sie einen Namen aus.

Git 2.28 hat die Möglichkeit hinzugefügt, einen ursprünglichen Verzweigungsnamen auszuwählen. Gleichzeitig haben Azure Repos, GitHub und andere Git-Hostinganbieter die Möglichkeit hinzugefügt, einen anderen ursprünglichen Branchnamen auszuwählen. Bisher wurde der Standard-Branch fast immer als master benannt. Der beliebteste alternative Name ist main. Weniger häufige Optionen umfassen 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 einer anderen Standardverzweigung 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. Designerpipelinen können im Web bearbeitet werden. YAML-Pipelines können in ihren jeweiligen Repositorys bearbeitet werden.

In-Flight Pull Requests

Retargetieren Sie jede geöffnete Pullanforderung auf die neue Standardverzweigung.

Vorhandene Klonen

Neue Klone des Repositories erhalten den neuen Standard-Branch. 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 Nicht-Codedateien, 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 einen Querystring für version enthält, z. B. &version=GBmybranchname, sollte diese URL aktualisiert werden. Glücklicherweise verfügen die meisten Links zur Standard-Branch nicht über ein version Segment und können wie sie sind verlassen werden. Sobald Sie die alte Standard-Branch löschen, werden alle Versuche, dorthin zu navigieren, dennoch zum neuen Standard-Branch weitergeleitet.

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 Build-Identitä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 Beitragen: Zulassen lautet.

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 unbemerkt Code in ein Repository Ihres Projekts einzuschleusen. Stellen Sie sicher, diese Berechtigung zu entfernen, wenn die Spiegelung nicht mehr benötigt wird.

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

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 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. Sehen Sie sich den neuen Standardbranch mit git checkout main an (falls main Ihr neuer Standardbranch ist).
3. Erstellen Sie einen neuen Branch zum Integrieren der zwei Branches in git checkout -b integrate.
4. Zusammenführen der alten Standardverzweigung mit git merge master (wenn master Ihre alte Standardverzweigung 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.