Wikipedia dit qu'une fusion à trois est moins sujette aux erreurs qu'une fusion à deux et qu'elle ne nécessite souvent pas l'intervention de l'utilisateur. Pourquoi est-ce le cas ?
Un exemple où une fusion à trois réussit et où une fusion à deux échoue serait utile.
Disons que vous et votre ami avez tous deux consulté un fichier et y avez apporté des modifications. Vous avez supprimé une ligne au début et votre ami a ajouté une ligne à la fin. Il a ensuite validé son fichier, et vous devez fusionner ses modifications dans votre copie.
Si vous effectuez une fusion à double sens (en d'autres termes, un diff), l'outil pourrait comparer les deux fichiers et constater que la première et la dernière ligne sont différentes. Mais comment saurait-il quoi faire avec ces différences ? La version fusionnée doit-elle inclure la première ligne ? Devrait-elle inclure la dernière ligne ?
Avec une fusion à trois, il peut comparer les deux fichiers, mais il peut aussi comparer chacun d'eux à la copie originale (avant que l'un de vous ne la modifie). Il peut donc voir que vous avez supprimé la première ligne et que votre ami a ajouté la dernière ligne. Et il peut utiliser ces informations pour produire la version fusionnée.
"Mais comment saurait-il quoi faire avec les différences ?" Je ne l'ai pas eu. S'il peut déjà voir les différences entre les deux fichiers (sans référence à l'original), pourquoi ne peut-il pas appliquer les deux changements en série dans l'ordre croissant des horodatages des fichiers ? C'est-à-dire : Il commence par la copie engagée de mon ami en la prenant pour le (nouvel) original (avec l'ajout de ligne en haut) et ensuite, par-dessus, il applique mes changements locaux (suppression de ligne en bas).
@Harry Dites que l'original avait trois lignes (ABC). On commence par la copie de mon ami (ABCD), et on la compare à la mienne (BC). Sans voir l'original, il pourrait penser que j'ai supprimé A et D, et que le résultat final devrait être BC.
@Harry si chaque fichier avait une liste de modifications horodatées depuis l'ancêtre commun, vous auriez une fusion à 3 voies. La méthode que vous décrivez nécessiterait de rembobiner le fichier jusqu'à l'ancêtre commun afin d'appliquer les différences chronologiquement. Formulé différemment, je ne suis pas sûr qu'il y ait une signification non ambiguë à "une différence horodatée entre deux fichiers sans référence à un ancêtre commun".
Cette diapositive d'une présentation de Perforce est intéressante :
La logique essentielle d'un outil de fusion à trois est simple :
- Comparer les fichiers de base, source et cible
- Identifiez les "chunks" dans le fichier des fichiers source et cible :
- Des morceaux qui ne correspondent pas à la base
- Des morceaux qui correspondent à la base
- Ensuite, rassemblez un résultat fusionné composé de :
- Les morceaux qui correspondent les uns aux autres dans les 3 fichiers
- Les morceaux qui ne correspondent pas à la base dans la source ou dans la cible mais pas dans les deux.
- Les morceaux qui ne correspondent pas à la base mais qui correspondent entre eux (c'est-à-dire qu'ils ont été modifiés de la même manière dans la source et dans la cible).
- Des espaces réservés pour les morceaux en conflit, à résoudre par l'utilisateur.
Notez que les "chunks" dans cette illustration sont purement symboliques. Chacun d'entre eux pourrait représenter des lignes dans un fichier, ou des nœuds dans une hiérarchie, ou même des fichiers dans un répertoire. Tout dépend de ce dont un outil de fusion particulier est capable.
Vous vous demandez peut-être quels sont les avantages d'une fusion à trois par rapport à une fusion à deux. En fait, il n'existe pas de fusion à deux voies, seulement des outils qui diffèrent deux fichiers et vous permettent de "fusionner" en choisissant des morceaux d'un fichier ou de l'autre.
Seule une fusion à 3 voies vous donne la possibilité de savoir si un morceau est ou non une modification de l'origine et si les modifications sont en conflit.
"si les changements entrent en conflit ou non". - la fusion à double sens (diff) ne montre-t-elle pas aussi un conflit (bien que l'information soit perdue en ce qui concerne la source du conflit) ?
Il est cependant courant dans Git d'avoir une fusion à 4 voies où la base n'est en fait pas la même. Une fusion à 3 est toujours préférable à une fusion à 2.
Une fusion à trois voies consiste à fusionner deux modifications d'un fichier de base au fur et à mesure qu'elles sont appliquées, par opposition à l'application d'une modification, puis à la fusion du résultat avec l'autre.
Par exemple, le fait d'avoir deux modifications où une ligne est ajoutée au même endroit pourrait être interprété comme deux ajouts, et non comme une modification d'une ligne.
Par exemple, le fichier a a été modifié par deux personnes, l'une ajoutant moose en ajoutant mouse .
#File a
dog
cat
#diff b, a
dog
+++ mouse
cat
#diff c, a
dog
+++ moose
catMaintenant, si nous fusionnons les changesets au fur et à mesure que nous les appliquons, nous obtiendrons (fusion à 3 voies)
#diff b and c, a
dog
+++ mouse
+++ moose
catMais si nous appliquons b, puis regardons le changement de b à c, il semblera que nous changeons juste un 'u' en 'o' (fusion à deux voies).
#diff b, c
dog
--- mouse
+++ moose
cat
J'ai écrit un post très détaillé à ce sujet . En fait, vous ne pouvez pas suivre les suppressions/ajouts dans les deux sens, ce qui est très, très improductif.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
