stratégies de fusion

Stratégies de fusion Git

Lorsque le travail est terminé et prêt à être fusionné dans la ligne principale de développement, nous devons choisir une stratégie de fusion.

Git combine les modifications provenant de différentes branches à l’aide de différentes méthodes, appelées « stratégies de fusion ». Après avoir sélectionné une stratégie de fusion, Git crée un nouveau commit de fusion combinant les modifications des branches spécifiées. Si aucune n’est précisée, la commande git merge sélectionne automatiquement une stratégie de fusion en fonction des branches fournies. L’option -s peut être utilisée pour spécifier le nom de la stratégie. Voici la liste des stratégies de fusion :

Récursive

stratégie de fusion git recursive

git merge -s recursive branch_name

Git sélectionne recursive comme stratégie par défaut lors du pull ou de la fusion de branches. La stratégie recursive peut détecter et gérer les fusions impliquant des renommages, mais elle ne peut pas utiliser les copies détectées.

Resolve

stratégie de fusion resolve

git merge -s resolve branch_name

La stratégie resolve utilise une fusion à 3 voies pour résoudre les branches et ne peut résoudre que deux HEAD à l’aide d’un algorithme de fusion à 3 voies. Elle est sûre et rapide, et détecte en détail les ambiguïtés de fusion en croix.

Octopus

stratégie de fusion octopus

git merge -s octopus branch1 branch2 branch3

Lorsque plusieurs branches sont passées à la commande de fusion, la stratégie octopus peut être utilisée pour les combiner en un seul commit. Octopus refuse si la fusion comporte des conflits nécessitant une résolution manuelle. L’utilisation de base d’Octopus consiste à regrouper des HEAD de branches de fonctionnalités présentant des similitudes.

Ours

stratégie de fusion ours

git merge -s ours branch_name

La stratégie ours résout plusieurs branches, mais le résultat est toujours celui du HEAD de la branche courante. Elle ignore très efficacement toutes les modifications de toutes les autres branches. Elle est destinée à remplacer un ancien historique de branches secondaires.

Subtree

stratégie de fusion subtree

git merge -s subtree branch_name

La stratégie subtree est une version modifiée de la stratégie recursive. Par exemple, nous fusionnons les arbres A et B. Lorsqu’il correspond à un sous-arbre de A, B est d’abord modifié pour refléter la structure arborescente de A. La modification peut être appliquée à l’ancêtre commun des arbres A et B.

Types de stratégies de fusion git

Commits de fusion (explicites)

Les fusions explicites sont considérées comme le type de fusion par défaut. Elles sont dites explicites car elles créent un nouveau commit de fusion, modifiant l’historique et affichant l’endroit où la fusion a été invoquée. Le contenu du commit de fusion est également considéré comme explicite, car il affiche les commits parents du commit de fusion.

Fusions Fast-Forward (implicites)

Les fusions fast-forward ne créent pas de commit de fusion. Elles déplacent simplement le pointeur de la branche cible vers l’avant jusqu’au dernier commit de la branche source. Ce comportement est déclenché automatiquement lorsque la branche cible n’a pas divergé de la branche source.

Fusions Squash

Squash est une option de fusion qui évite de créer un commit de fusion. Une fusion squash prend tous les commits de la branche source et les combine en un seul nouveau commit, qui est ensuite appliqué à la branche cible. Cela est généralement exécuté à l’aide de l’indicateur --squash lors d’une fusion ou d’un rebase interactif. L’historique des commits de la branche source devient un seul commit squashé sur la branche cible.

Options de la stratégie de fusion récursive de git

ours	Force les parties en conflit à être résolues automatiquement en privilégiant la version « nôtre ». Les modifications de l’autre arbre qui ne sont pas en conflit avec notre côté sont répercutées dans la sortie de fusion.
theirs	Privilégie l’autre arbre en cours de fusion lors de la résolution des conflits. Il n’existe pas de stratégie de fusion « theirs », contrairement à « ours ».
patience	Passe beaucoup de temps à éviter les mauvaises fusions qui se produisent à cause de lignes correspondantes peu importantes.
diff-algorithm	Indique à « merge-recursive » d’utiliser un autre algorithme de diff qui aide à éviter les mauvaises fusions sur des lignes correspondantes peu importantes.
ignore-space-change / ignore-all-space	Cible les caractères d’espacement. Les changements d’espacement mélangés à d’autres changements ne sont pas ignorés.
renormalize	Exécute une sortie et une réintégration sur tous les stades du fichier lors de la résolution d’une fusion à 3 voies.
no-normalize	Désactive l’option renormalize.
no-renames	Ignore les fichiers renommés pendant la fusion.
find-renames=n	Active la détection des renommages avec un seuil de similarité. Le seuil par défaut est de 50 %.
subtree	Travaille sur les métadonnées de chemin de l’arbre pour faire correspondre les arbres.

Practice

What are the different merge strategies in Git and their characteristics?

The 'recursive' merge strategy is the default when merging branches and can handle renames but not detected copies.The 'resolve' strategy uses a 3-way merge algorithm and is safe and fast for resolving branches.The 'octopus' strategy is used when merging two or more branches and refuses merges with conflicts needing manual resolution.The 'ours' strategy results in the merge commit always reflecting the changes of the current branch HEAD, ignoring other branches.The 'subtree' strategy is a modified version of the recursive strategy, used for merging trees while adjusting their structures.Explicit merges create a new merge commit and display parent commits of the merge commit.Implicit merges via rebase or fast-forward do not create a new merge commit.A 'squash' merge combines all commits from the target branch into a single commit applied to the merge base branch HEAD.The 'ours' strategy auto-resolves conflicts by favoring changes from the other merging tree.