Stratégies de fusion et fusion Squash

  • Article

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

Lorsque vous effectuez une demande de tirage, vous fusionnez la branche de rubrique dans votre branche par défaut, généralementmain. Cette fusion ajoute les commits de la branche de rubrique à votre branche primaire et crée un commit de fusion pour rapprocher les conflits entre la branche par défaut et la branche de rubrique. Les commentaires et la discussion dans la demande de tirage fournissent un contexte supplémentaire pour les modifications apportées à la branche de rubrique.

Exemple de fusion régulière à partir d’une demande de tirage.

L’historique des commits sur votre main branche (ou d’autres branches par défaut) ne suit pas une ligne droite, en raison de l’historique de la branche de rubrique associée. À mesure qu’un projet prend de l’ampleur, le nombre de branches de rubrique est de plus en plus important, ce qui rend l’historique de branches par défaut de plus en plus difficile à suivre.

La branche par défaut est une représentation précise de l’historique de chaque branche de rubrique, mais il est difficile de répondre à des questions plus larges sur le développement de votre projet.

Fusion Squash

La fusion Squash est une option de fusion qui vous permet de condenser l’historique Git des branches de rubrique lorsque vous effectuez une demande de tirage. Au lieu d’ajouter chaque commit sur une branche de rubrique à l’historique de la branche par défaut, une fusion Squash ajoute toutes les modifications de fichier à un seul nouveau commit sur la branche par défaut. Le commit de fusion Squash n'a pas de référence à la branche topic; il produira un nouveau commit qui contiendra toutes les modifications de la branche topic. En outre, il est recommandé de supprimer la branche de rubrique pour éviter toute confusion.

Diagramme de fusion Squash dans les demandes de tirage dans Azure Repos.

Une façon simple d’y penser est que la fusion Squash vous donne uniquement les modifications de fichier, et une fusion régulière vous donne les modifications de fichier et l’historique de commit.

En quoi une fusion Squash est-elle utile ?

La fusion Squash maintient vos historiques branche par défaut propres et faciles à suivre sans exiger de modifications de workflow pour votre équipe. Les contributeurs à la branche de rubrique fonctionnent comme ils le souhaitent dans la branche de rubrique, et les branches par défaut conservent un historique linéaire grâce à l’utilisation de fusions Squash. L’historique de commit d’une main branche mise à jour avec fusions Squash comporte un commit pour chaque branche fusionnée. Vous pouvez parcourir cet historique pour savoir exactement quand le travail a été effectué.

Considérations à prendre en compte lors de la fusion Squash

La fusion Squash condense l’historique des modifications dans votre branche par défaut. Il est donc important de travailler avec votre équipe pour décider quand vous devez faire une fusion Squash ou quand vous souhaitez conserver l’historique de commit complet d’une branche de rubrique. Lors d’une fusion Squash, il est recommandé de supprimer la branche source. La suppression de la branche source empêche toute confusion, car la branche de rubrique elle-même n’a pas de commit qui la fusionne dans le branche par défaut.

Effectuer des demandes de tirage avec fusion Squash

Vous pouvez choisir de faire une fusion Squash lors de la fin d’une demande de tirage dans Azure Repos.

Choisissez Commit Squash sous Type de fusion dans la boîte de dialogue Terminer la demande de tirage pour faire une fusion Squash de la branche de rubrique.

Capture d’écran de la fermeture d’une demande de tirage avec une fusion Squash dans Azure Repos.

Bases de fusion multiples

L’onglet Fichiers d’une demande de tirage détecte les différences par une comparaison à trois côtés. L’algorithme prend en compte le dernier commit dans la branche cible, le dernier commit dans la branche source et leur base de fusion commune (c’est-à-dire le meilleur ancêtre commun). L’algorithme est une méthode rapide, économique et fiable de détection des modifications. Malheureusement, dans certains cas, il existe plusieurs bases vraies. Dans la plupart des référentiels, cette situation est rare, mais dans les grands référentiels avec de nombreux utilisateurs actifs, elle peut être courante. Vous pouvez vérifier manuellement s'il existe plusieurs bases de fusion entre les branches. Pour ce faire, exécutez la commande git merge-base --all feature master. Azure DevOps détecte l'existence de plusieurs bases de fusion pour chaque PR. Si c'est le cas, Azure DevOps affiche le message « Bases de fusion multiples détectées. La liste des commits affichée peut être incomplète » pour le PR. Pendant qu'Azure DevOps effectue la détection de bases de fusion multiples, il ne vérifie pas si la base de fusion potentielle a déjà été fusionnée ou non. Ce contrôle est effectué par git merge-base. C'est pourquoi Azure DevOps peut afficher le message, même si git merge-base ne signale qu'une seule base de fusion.

Remarque

Si vous avez perdu des modifications lors de la révision d'un PR, assurez-vous que la présence de plusieurs bases de fusion n'est pas la cause principale.

Les scénarios suivants sont détectés par Azure DevOps comme des bases multiples (les bases de fusion sont indiquées par les numéros 1 et 2) :

  • Fusions croisées (également appelées criss-cross) entre différentes branches (signalées par Azure DevOps ainsi que git merge-base)
---1---o---A
    \ /
     X
    / \
---2---o---o---B
  • Fusion d'une branche vers les deux autres (signalé par Azure DevOps, mais pas par git merge-base qui élimine la base de fusion 2)
---1---o---o---o---A
    \         /
     \-------2
      \       \
       \---o---o---o---B
  • Traitement des séquelles des reverts de la branche principale, par exemple modifier le commit de fusion.
*   42bb2d2 (HEAD, A) Amended merge commit
|\  
| | *   67c9bb8 (other) Merge branch 'A' into B
| | |\  
| |/ /  
|/| /   
| |/    
| * fa78e32 add second commit
* | 15845c9 add first commit
|/  
* 6a52130 add init
  • Réutilisation active des branches de fonctionnalités
  • Autres manipulations non intuitives et alambiqués avec des restaurations, des cherry-pick et des fusions

La détection de base de fusion multiple fait partie de la sensibilisation à la sécurité. S’il existe plusieurs bases de fusion, l’algorithme de diff de fichier pour l’interface utilisateur risque de ne pas détecter correctement les modifications de fichier, en fonction de la base de fusion choisie. Si les fichiers de la demande de tirage ont des versions différentes entre les bases de fusion, un avertissement de base de fusion multiple se produit.

Pour plus d’informations, consultez la documentation git officielle.

Risques de sécurité potentiels liés à la fusion à partir de plusieurs bases

  • Un utilisateur malveillant peut abuser de l’algorithme d’interface utilisateur pour valider des modifications malveillantes qui ne sont pas présentes dans la demande de tirage.
  • Si les modifications proposées dans la demande de tirage se trouvent déjà dans la branche cible, elles s’affichent sous l’onglet Fichiers, mais elles peuvent ne pas déclencher des stratégies de branche qui sont mappées aux modifications de dossier.
  • Il se peut que deux ensembles de modifications apportées aux mêmes fichiers à partir de plusieurs bases de fusion ne soient pas présents dans la demande de tirage. Ce cas peut créer des lacunes logiques perfides.

Comment résoudre le problème de plusieurs bases de fusion

Avoir plusieurs bases de fusion n’est pas nécessairement mauvais, mais vous devez doublement vérifier que tout va bien. Pour vous débarrasser de plusieurs bases de fusion, liez les branches à un ancêtre commun en rebasant votre branche sur la cible ou en fusionnant la cible dans votre branche. Ces actions suppriment le message d’avertissement et vous aident à vérifier si les modifications réelles sont correctes.

L’une des approches consiste à réinitialiser de manière réversible et à cacher votre progression avant de rebaser ou de fusionner. Vous pouvez ensuite créer une nouvelle branche ou en rebaser une branche vide et appliquer vos modifications à partir d’un point clair. Ce processus peut nécessiter une poussée forcée à distance si vos modifications sont déjà là.

Comment éviter le problème de plusieurs bases de fusion

Voici des conseils généraux pour éviter le problème de base de fusion multiple :

  • Lors de la préparation d’une demande de tirage, créez des branches de fonctionnalité à partir des dernières versions de la branche primaire ou release.
  • Évitez de créer des branches qui ne proviennent pas directement de branches stables de votre référentiel, sauf si nécessaire.

Que faire si le problème de plusieurs bases de fusion réapparaît

Dans les grands référentiels avec de nombreux contributeurs actifs, ce problème peut être particulièrement gênant. Même si vous vous débarrassez de plusieurs bases via la fusion, la situation peut réapparaître. Si quelqu’un ferme une demande de tirage de longue date, cela peut recréer la situation. Même si des stratégies de build et des tests sont en cours d’exécution, vous n’avez aucun moyen d’effectuer la demande de tirage. La réinitialisation et le démarrage d’une nouvelle branche peuvent vous aider. Si rien n’est changé, vos modifications sont probablement claires, même si la situation se répète.

Étapes suivantes