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 Standard-Branch 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 eine Verzweigung vorhanden ist, ist sie bereits die Standardeinstellung. 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. Ohne Einschränkungen durch die verwendeten Tools oder das Team, in dem Sie arbeiten, funktionieren alle gültigen Verzweigungsnamen.

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-Pullanforderungen

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 origin durch den Namen Ihres Fernzugriffs, wenn es sich um etwas anderes handelt), um Ihre Ansicht der Standardverzweigung des Fernzugriffs zu aktualisieren. Zukünftige neue Filialen sollten auf dem neuen Standard 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 vorübergehend eine temporäre Spiegelung zwischen dem alten Standard und dem neuen Standard einrichten. Auf diese Weise müssen Ihre Endbenutzer ihre Arbeit nicht erneut durchführen, wenn sie weiterhin auf den alten Standardwert zurückgreifen. Wir verwenden Azure Pipelines , um diese temporäre Spiegelung einzurichten.

Die Spiegelungspipeline

1. Für alle vorhandenen CI-Builds, aktualisieren Sie diese so, dass sie gegen Ihren neuen Standardzweig anstelle des alten ausgelöst werden.

2. Erteilen Sie der Build-Identität die Berechtigung "Mitwirken" für Ihr Repository. Navigieren Sie zu Projekteinstellungen>Repositorys>(Ihr Repository)>Berechtigungen. Es kann bis zu zwei Identitäten geben, eine für den Projektsammlungsbuilddienst und die andere für den Projektbuilddienst. Stellen Sie sicher, dass die Berechtigung Beitragen: Zulassen lautet.

3. Wenn die neue Standardverzweigung über Verzweigungsrichtlinien verfügt, erteilen Sie auch der Buildidentität die Berechtigung, Richtlinien beim Pushen zu 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 in der neuen Standardverzweigung 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 an master oder an main erfolgt. Sie werden synchronisiert, solange neue Commits nicht gleichzeitig auf beiden Zweigen eingehen.

Wenn die Pipeline mit einer Fehlermeldung wie "Updates wurden abgelehnt, da sich eine Push-Verzweigungsspitze hinter der Fernbedienung befindet" fehlschlägt, muss jemand die alte Verzweigung manuell in die neue Verzweigung zusammenführen.

1. Klonen Sie das Repository und cd in dessen 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 zur Integration der beiden Branches mit 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 und schließen Sie dann einen Pull Request in den neuen Standardbranch ab.
6. Die Spiegelungspipeline sollte dann die Spiegelung des Zusammenführungs-Commits wieder auf den alten Standardwert anwenden.