Changer de branche par défaut

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

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.

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 référentiel. 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 référentiel 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.

Remarque

Pour modifier la branche par défaut, vous devez avoir la permission Modifier les stratégies. Pour plus d'informations, voir Définir les autorisations de référentiel Git.

1. Sous votre référentiel de projet, sélectionnez Branches.

2. Dans la page Branches, sélectionnez Autres options en regard de la nouvelle branche par défaut souhaitée, puis choisissez Définir comme branche par défaut.

   

3. Après avoir défini la nouvelle branche par défaut, vous pouvez supprimer la valeur par défaut précédente si vous le souhaitez.

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 liées aux outils que vous utilisez ou à l’équipe à laquelle vous appartenez, n’importe quel nom de branche valide fonctionnera.

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 sa vue 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’auront pas de segment version et peuvent être laissés comme tel. En outre, une fois que vous supprimez l’ancienne branche par défaut, les tentatives d’accès à celle-ci seront prises vers la nouvelle branche par défaut quoi qu’il arrive.

Mise en miroir temporaire

Un référentiel 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 à 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.

Notes

Cette section utilise le langage qui est à l’opposé de la perspective de Microsoft. Plus précisément, le mot master apparaît à plusieurs endroits cohérents avec la façon dont il a été utilisé dans Git. L’objectif de cette rubrique est d’expliquer comment basculer vers un langage plus inclusif, tel que main. Éviter toute mention de master rendrait les instructions beaucoup plus difficiles à comprendre.

Pipeline de mise en miroir

Notes

Ces instructions ne sont pas infaillibles et la configuration de votre référentiel peut nécessiter des modifications supplémentaires, telles que des autorisations et des stratégies.

Avertissement

Si les anciennes et nouvelles branches par défaut sont mises à jour avant l’exécution de ce pipeline, le pipeline ne pourra pas mettre en miroir les modifications. Une personne doit fusionner manuellement l’ancienne branche par défaut dans la nouvelle branche par défaut pour l’exécuter automatiquement.

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 référentiel l’autorisation Contribuer à l’identité de build. Accédez aux autorisations des>référentiels des>paramètres du projet>(votre référentiel). Il peut y avoir jusqu’à deux identités, une pour le service de build de collection de projets et l’autre pour le service de build 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 à l’autorisation Stratégies de contournement lors de l’envoi. 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 ligne git push 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 nouveau pipeline, en choisissant « Git Azure Repos » et « Fichier YAML Azure Pipelines existant » dans l’Assistant. Choisissez le fichier mirror.yml que vous avez ajouté à l’étape précédente. Enregistrez et exécutez le pipeline.

Dépannage

Ce pipeline s’exécute chaque fois qu’il y a un envoi vers master ou vers main. Elle 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 d’envoi 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 (si main est 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 (si master est votre ancienne branche par défaut).
5. Envoyez la nouvelle branche, puis ouvrez et terminez une demande de tirage 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.