De standaardbranch wijzigen

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

De standaardbranch is de eerste vertakking die Git zal uitchecken op een nieuwe kloon. Pull-aanvragen zijn standaard gericht op deze vertakking.

We doorlopen het proces voor het wijzigen van de standaardbranch. We behandelen ook andere zaken die u moet overwegen en bijwerken bij het aanbrengen van deze wijziging. Ten slotte kijken we naar een hulpprogramma voor het versoepelen van de overgang.

Een nieuwe standaardbranch instellen

U kunt een andere vertakking gebruiken dan main voor nieuwe wijzigingen of uw hoofdlijn voor ontwikkeling in uw opslagplaats wijzigen. Als u de standaardbranchnaam voor nieuwe opslagplaatsen wilt wijzigen, raadpleegt u Alle instellingen en beleidsregels voor opslagplaatsen.

Als u de standaardvertakking van uw opslagplaats voor het samenvoegen van nieuwe pull-aanvragen wilt wijzigen, hebt u ten minste twee vertakkingen nodig. Als er slechts één vertakking is, is dit al de standaardinstelling. U moet een tweede vertakking maken om de standaardinstelling te wijzigen.

Notitie

Als u de standaardbranch wijzigt, moet u de machtiging Beleid bewerken hebben. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie.

1. Selecteer Vertakkingen onder uw projectopslagplaats.

2. Selecteer op de pagina Branches meer opties naast de nieuwe standaardbranch die u wilt gebruiken en kies Instellen als standaardbranch.

   

3. Nadat u de nieuwe standaardbranch hebt ingesteld, kunt u desgewenst de vorige standaardwaarde verwijderen.

Er zijn andere aspecten die u moet overwegen voordat u deze wijziging aanbrengt.

Kies een naam

Git 2.28 heeft de mogelijkheid toegevoegd om een initiële vertakkingsnaam te kiezen. Tegelijkertijd hebben Azure-opslagplaatsen, GitHub en andere Git-hostingproviders de mogelijkheid toegevoegd om een andere initiële vertakkingsnaam te kiezen. Voorheen was de standaardbranch bijna altijd benoemd master. De populairste alternatieve naam is main. Minder gangbare opties zijn onder andere trunk en development. Afwezige beperkingen van de hulpprogramma's die u gebruikt of het team waaraan u werkt, elke geldige vertakkingsnaam werkt.

Andere systemen bijwerken

Wanneer u overstapt op een andere standaardbranch, kunnen andere onderdelen van uw werkstroom worden beïnvloed. U moet rekening houden met deze onderdelen wanneer u een wijziging plant.

Pipelines

Werk de CI-triggers voor alle pijplijnen bij. Designer-pijplijnen kunnen worden bewerkt op internet. YAML-pijplijnen kunnen worden bewerkt in hun respectieve opslagplaatsen.

Pull-aanvragen tijdens de vlucht

Retarget elke open pull-aanvraag naar de nieuwe standaardvertakking.

Bestaande klonen

Nieuwe kloonnen van de opslagplaats krijgen de nieuwe standaardbranch. Na de switch moet iedereen met een bestaande kloon worden uitgevoerd git remote set-head origin -a (vervangen door origin de naam van hun externe als dit iets anders is) om de weergave van de standaardvertakking van de externe bij te werken. Toekomstige nieuwe vertakkingen moeten zijn gebaseerd op de nieuwe standaardinstelling.

Binnenkomende koppelingen

Sommige bladwijzers, documenten en andere niet-codebestanden die verwijzen naar bestanden in Azure-opslagplaatsen, moeten worden bijgewerkt. De naam van de vertakking voor een bestand of map kan worden weergegeven in de URL.

Als een URL bijvoorbeeld &version=GBmybranchnameeen querytekenreeks versionbevat, moet die URL worden bijgewerkt. Gelukkig hebben version de meeste koppelingen naar de standaardvertakking geen segment en kunnen ze als zodanig worden achtergelaten. Als u de oude standaardvertakking hebt verwijderd, wordt er toch naar de nieuwe standaardvertakking genavigeert.

Tijdelijke spiegeling

Een Git-opslagplaats kan slechts één standaardbranch hebben. U kunt echter gedurende een tijdje ad-hocspiegeling instellen tussen uw oude standaard en uw nieuwe standaardwaarde. Als uw eindgebruikers op deze manier doorgaan met pushen naar de oude standaardwaarde, hoeven ze het werk niet opnieuw uit te voeren. We gebruiken Azure Pipelines om deze tijdelijke spiegeling in te stellen.

Notitie

In deze sectie wordt de taal gebruikt die in strijd is met het perspectief van Microsoft. In het bijzonder wordt het woord master op verschillende plaatsen weergegeven, consistent met de wijze waarop het in Git wordt gebruikt. Het doel van dit onderwerp is om uit te leggen hoe u overschakelt naar inclusievere taal, zoals main. Het vermijden van master alle vermeldingen zou de richtingen veel moeilijker te begrijpen maken.

De spiegelingspijplijn

Notitie

Deze instructies zijn niet dwaasbestendig en de installatie van uw opslagplaats vereist mogelijk aanvullende wijzigingen, zoals het losmaken van machtigingen en beleidsregels.

Waarschuwing

Als de oude en nieuwe standaardbranches beide worden bijgewerkt voordat deze pijplijn wordt uitgevoerd, kan de pijplijn de wijzigingen niet spiegelen. Iemand moet de oude standaardbranch handmatig samenvoegen in de nieuwe standaardbranch om deze automatisch weer uit te voeren.

1. Voor alle bestaande CI-builds moet u deze bijwerken om te activeren voor uw nieuwe standaardbranch in plaats van de oude.

2. Verdeel de build-identiteit Bijdragen aan uw opslagplaats. Navigeer naar Project Instellingen> Repositories> (uw opslagplaats)>-machtigingen. Er kunnen maximaal twee identiteiten zijn, één voor de buildservice van de projectverzameling en de andere voor de projectbuildservice. Zorg ervoor dat de machtiging Bijdragen staat toegestaan.

3. Als de nieuwe standaardvertakking vertakkingsbeleid heeft, verleent u ook de build-identiteit de bypass-beleidsregels bij het pushen van machtigingen. Deze machtiging is een beveiligingsrisico omdat een kwaadwillende gebruiker een pijplijn kan maken om code in te sluipen in een opslagplaats in uw project. Wanneer spiegeling niet meer nodig is, moet u deze machtiging verwijderen.

4. Voeg een nieuw bestand mirror.yml toe aan uw opslagplaats in de nieuwe standaardbranch. In dit voorbeeld wordt ervan uitgegaan dat de oude standaardbranch was master en de nieuwe is main. Werk de triggervertakkingen en de git push lijn bij als uw vertakkingsnamen verschillen.

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. Maak een nieuwe pijplijn en kies 'Azure Repos Git' en 'Existing Azure Pipelines YAML file' in de wizard. Kies het mirror.yml bestand dat u in de vorige stap hebt toegevoegd. Sla de pijplijn op en voer deze uit.

Probleemoplossing

Deze pijplijn wordt telkens uitgevoerd wanneer er een push naar master of naar mainwordt uitgevoerd. Ze worden gesynchroniseerd zolang nieuwe doorvoeringen niet tegelijkertijd op beide vertakkingen aankomen.

Als de pijplijn mislukt met een foutbericht zoals 'Updates zijn geweigerd omdat een gepushte vertakkingstip zich achter de externe locatie bevindt', moet iemand de oude vertakking met de hand samenvoegen in de nieuwe vertakking.

1. Kloon de opslagplaats en cd in de map.
2. Bekijk de nieuwe standaardbranch met git checkout main (als main dit uw nieuwe standaardbranch is).
3. Maak een nieuwe vertakking voor het integreren van de twee vertakkingen met git checkout -b integrate.
4. Voeg de oude standaardbranch samen met git merge master (als master dit uw oude standaardbranch is).
5. Push de nieuwe vertakking en open en voltooi een pull-aanvraag in de nieuwe standaardbranch.
6. De spiegelingspijplijn moet vervolgens zorgen voor het spiegelen van de samenvoegdoorvoering naar de oude standaardwaarde.