Changer de branche par défaut

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

La branche par défaut est la première branche que Git va extraire sur un nouveau clone. En outre, les demandes de tirage ciblent cette branche par défaut.

Nous allons parcourir le processus de modification de la branche par défaut. Nous aborderons également d’autres éléments que vous devez prendre en compte et mettre à jour lors de cette modification. Enfin, nous examinerons un outil pour faciliter la transition.

Prerequisites

Définir une nouvelle branche par défaut

Vous pouvez utiliser une branche autre que main pour les nouvelles modifications ou modifier votre ligne de développement principale dans votre dépôt. Pour modifier le nom de branche par défaut pour les nouveaux référentiels, consultez Tous les paramètres et stratégies de référentiels.

Pour modifier la branche par défaut de votre dépôt pour fusionner de nouvelles demandes de tirage, vous avez besoin d’au moins deux branches. S’il n’existe qu’une seule branche, il s’agit déjà de la valeur par défaut. Vous devez créer une deuxième branche pour modifier la valeur par défaut.

Il existe d’autres aspects à prendre en compte avant d’apporter cette modification.

Choisir un nom

Git 2.28 a ajouté la possibilité de choisir un nom de branche initiale. En même temps, Azure Repos, GitHub et d’autres fournisseurs d’hébergement Git ont ajouté la possibilité de choisir un autre nom de branche initiale. Auparavant, la branche par défaut était presque toujours nommée master. Le nom alternatif le plus populaire est main. Les options moins courantes incluent trunk et development. En l’absence de restrictions des outils que vous utilisez ou de l’équipe sur utilisant, tout nom de branche valide fonctionne.

Mettre à jour d’autres systèmes

Lorsque vous passez à une autre branche par défaut, d’autres parties de votre flux de travail peuvent être affectées. Vous devez prendre en compte ces parties lorsque vous planifiez une modification.

Pipelines

Mettez à jour les déclencheurs CI pour tous les pipelines. Les pipelines du concepteur peuvent être modifiés sur le web. Les pipelines YAML peuvent être modifiés dans leurs référentiels respectifs.

Demandes de tirage en cours

Reciblez chaque demande de tirage ouverte vers la nouvelle branche par défaut.

Clones existants

Les nouveaux clones du référentiel obtiennent la nouvelle branche par défaut. Après le changement, tout le monde disposant d’un clone existant doit s’exécuter git remote set-head origin -a (en remplaçant origin par le nom de son serveur distant s’il s’agit d’un autre élément) pour mettre à jour son affichage de la branche par défaut de la branche distante. Les nouvelles branches futures doivent être basées sur la nouvelle valeur par défaut.

Liens entrants

Certains signets, documents et autres fichiers non codés pointant vers des fichiers dans Azure Repos doivent être mis à jour. Le nom de branche d’un fichier ou d’un répertoire peut apparaître dans l’URL.

Si une URL contient une chaîne de requête pour version, par exemple &version=GBmybranchname, cette URL doit être mise à jour. Heureusement, la plupart des liens vers la branche par défaut n’ont pas de version segment et peuvent être laissés as-is. En outre, une fois que vous supprimez l’ancienne branche par défaut, les tentatives d’accès à celui-ci seront prises vers la nouvelle branche par défaut de toute façon.

Mise en miroir temporaire

Un dépôt Git ne peut avoir qu’une seule branche par défaut. Toutefois, pendant un certain temps, vous pouvez configurer la mise en miroir ad hoc entre votre ancienne valeur par défaut et votre nouvelle valeur par défaut. De cette façon, si vos utilisateurs finaux continuent d’envoyer (push) à l’ancienne valeur par défaut, ils n’auront pas besoin de rétablir le travail à leur fin. Nous allons utiliser Azure Pipelines pour configurer cette mise en miroir temporaire.

Pipeline de mise en miroir

1. Pour toutes les builds CI existantes, mettez-les à jour pour les déclencher sur votre nouvelle branche par défaut au lieu de l’ancienne.

2. Accordez à votre dépôt l’autorisation Contribuer à l’identité de build. Accédez auxréférentiels des>paramètres> du projet (votre dépôt)>Autorisations. Il peut y avoir jusqu’à deux identités, une pour le service de génération de collection de projets et l’autre pour le service de génération de projet. Vérifiez que l’autorisation Contribuer indique Autoriser.

3. Si la nouvelle branche par défaut a des stratégies de branche, accordez également l’identité de build aux stratégies de contournement lors de l’envoi d’autorisations . Cette autorisation est un risque de sécurité, car un utilisateur malveillant peut créer un pipeline pour insérer du code dans un référentiel dans votre projet. Lorsque la mise en miroir n’est plus nécessaire, veillez à supprimer cette autorisation.

4. Ajoutez un nouveau fichier mirror.yml à votre référentiel dans la nouvelle branche par défaut. Dans cet exemple, nous supposons que l’ancienne branche par défaut était master et que la nouvelle branche est main. Mettez à jour les branches déclenchées et la git push ligne si vos noms de branche sont différents.

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. Créez un pipeline, en choisissant « Git Azure Repos » et « Fichier YAML Azure Pipelines existant » dans l’Assistant. Choisissez le mirror.yml fichier que vous avez ajouté à l’étape précédente. Enregistrez et exécutez le pipeline.

Résolution des problèmes

Ce pipeline s’exécute chaque fois qu’il y a une transmission (push) vers master ou vers main. Il les maintient synchronisés tant que les nouvelles validations n’arrivent pas simultanément sur les deux branches.

Si le pipeline commence à échouer avec un message d’erreur tel que « Les mises à jour ont été rejetées parce qu’un conseil de branche push se trouve derrière son distant », une personne doit fusionner l’ancienne branche dans la nouvelle branche en main.

1. Clonez le référentiel et cd dans son répertoire.
2. Consultez la nouvelle branche par défaut avec git checkout main (s’il s’agit main de votre nouvelle branche par défaut).
3. Créez une branche pour intégrer les deux branches avec git checkout -b integrate.
4. Fusionnez l’ancienne branche par défaut avec git merge master (s’il s’agit master de votre ancienne branche par défaut).
5. Envoyez (push) la nouvelle branche, puis ouvrez et terminez une demande de tirage (pull request) dans la nouvelle branche par défaut.
6. Le pipeline de mise en miroir doit ensuite s’occuper de la mise en miroir de la validation de fusion vers l’ancienne valeur par défaut.