Ändern des Standardbranches

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

Die Standardverzweigung ist die erste Verzweigung, die Git auf einem neuen Klon auscheckt. Außerdem zielen Pullanforderungen standardmäßig auf diese Verzweigung ab.

Wir werden den Prozess zum Ändern der Standardverzweigung 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 die Standardverzweigung fast immer benannt master. Der beliebteste alternative Name ist main. Weniger häufige Optionen umfassen trunk und development. Abwesend von den Tools, die Sie verwenden oder das Team Sie verwenden, 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 Klonen des Repositorys erhalten den neuen Standardverzweigung. Nach dem Wechsel sollte jeder mit einem vorhandenen Klon ausgeführt werden git remote set-head origin -a (ersetzen origin durch den Namen seiner Remote, wenn es sich um etwas anderes handelt), um die Ansicht der Standardverzweigung des Remotes 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 Verzweigungsname für eine Datei oder ein Verzeichnis kann in der URL angezeigt werden.

Wenn eine URL eine Abfragezeichenfolge für version, z &version=GBmybranchname. B. , enthält, sollte diese URL aktualisiert werden. Glücklicherweise verfügen die meisten Links zu der Standardverzweigung nicht über ein version Segment und können as-isverlassen werden. Wenn Sie auch den alten Standardverzweigung löschen, werden Versuche, dorthin zu navigieren, trotzdem zum neuen Standard weitergeleitet.

Temporäre Spiegelung

Ein Git-Repository kann nur über einen Standardverzweigung verfügen. Sie können die Ad-hoc-Spiegelung jedoch für eine Weile zwischen dem alten Standard und dem neuen Standard einrichten. Auf diese Weise müssen Endbenutzer die Arbeit am Ende nicht wiederholen, wenn Die Endbenutzer weiterhin auf den alten Standardwert übertragen. Wir verwenden Azure Pipelines , um diese temporäre Spiegelung einzurichten.

Die Spiegelungspipeline

1. Aktualisieren Sie sie für alle vorhandenen CI-Builds so, dass sie anstelle der alten aus dem neuen Standardverzweigung ausgelöst werden .

2. Erteilen Sie der Buildidentität die Berechtigung "Mitwirken" für Ihr Repository. Navigieren Sie zuProject-Einstellungsrepositorys>>(Ihr Repository)>-Berechtigungen. Es kann bis zu zwei Identitäten geben, eine für den Projektsammlungsbuilddienst und den anderen für den Projektbuilddienst. Stellen Sie sicher, dass die Berechtigung "Mitwirken " "Zulassen" besagt.

3. Wenn die neue Standardverzweigung Über Verzweigungsrichtlinien verfügt, erteilen Sie auch der Buildidentität die Umgehungsrichtlinien beim Pushen der Berechtigung. Diese Berechtigung ist ein Sicherheitsrisiko, da ein böswilliger Benutzer eine Pipeline erstellen könnte, um Code in einem Repository in Ihrem Projekt zu sneak code zu senden. Wenn die Spiegelung nicht mehr benötigt wird, müssen Sie diese Berechtigung entfernen.

4. Fügen Sie ihrem Repository in der neuen Standardverzweigung eine neue Datei mirror.yml hinzu. In diesem Beispiel wird davon ausgegangen, dass die alte Standardverzweigung war master und die neue verzweigt ist main. Aktualisieren Sie die auslösenden Verzweigungen und die git push Zeile, wenn die Verzweigungsnamen 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 Datei aus, die mirror.yml 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 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 ihr Verzeichnis.
2. Sehen Sie sich die neue Standardverzweigung an git checkout main (wenn main dies der neue Standardverzweigung ist).
3. Erstellen Sie eine neue Verzweigung für die Integration der beiden Verzweigungen in git checkout -b integrate.
4. Zusammenführen der alten Standardverzweigung mit git merge master (wenn master die alte Standardverzweigung vorhanden ist).
5. Pushen Sie die neue Verzweigung, öffnen und schließen Sie dann eine Pullanforderung in die neue Standardverzweigung ab.
6. Die Spiegelungspipeline sollte dann die Spiegelung des Zusammenführungs-Commits wieder auf den alten Standardwert anwenden.