Quand utiliseriez-vous les différentes stratégies de fusion Git?
Dans la page de manuel sur git-merge, vous pouvez utiliser un certain nombre de stratégies de fusion.
résoudre - Cela ne peut résoudre que deux têtes (c'est-à-dire la branche actuelle et une autre branche à partir de laquelle vous avez tiré) à l'aide de l'algorithme de fusion à 3 voies. Il essaie de détecter soigneusement les ambiguïtés de fusion croisées et est généralement considéré comme sûr et rapide.
récursif - Ceci ne peut résoudre que deux têtes en utilisant l'algorithme de fusion à 3 voies. Lorsqu'il existe plusieurs ancêtres communs pouvant être utilisés pour la fusion à 3 voies, un arbre fusionné des ancêtres communs est créé et utilisé comme arbre de référence pour la fusion à 3 voies. Il a été rapporté que cela entraînait moins de conflits de fusion sans causer de fausses fusions lors des tests effectués sur les commits de fusion réels extraits de l'historique de développement du noyau Linux 2.6. De plus, cela permet de détecter et de gérer les fusions impliquant un renommage. C'est la stratégie de fusion par défaut lors de l'extraction ou de la fusion d'une branche.
octopus - Cela résout plus d'un cas à deux têtes, mais refuse d'effectuer une fusion complexe nécessitant une résolution manuelle. Il est principalement destiné à être utilisé pour regrouper des têtes de branches de sujets. C'est la stratégie de fusion par défaut lors de l'extraction ou de la fusion de plusieurs branches.
our our - Ceci résout un nombre quelconque de têtes, mais le résultat de la fusion est toujours la tête de branche actuelle. Il est destiné à être utilisé pour remplacer l’ancienne histoire de développement des branches latérales.
subtree - Ceci est une stratégie récursive modifiée. Lors de la fusion des arbres A et B, si B correspond à un sous-arbre de A, B est d'abord ajusté pour correspondre à la structure arborescente de A, au lieu de lire les arbres au même niveau. Cet ajustement est également effectué sur l'arbre des ancêtres commun.
Quand devrais-je spécifier quelque chose de différent de celui par défaut? Quels sont les meilleurs scénarios pour chacun?
Je ne suis pas familier avec resol, mais j'ai utilisé les autres:
Récursif
Récursif est la valeur par défaut pour les fusions sans avance rapide. Nous sommes tous familiers avec celui-là.
Poulpe
J'ai utilisé le poulpe lorsque j'ai eu plusieurs arbres à fusionner. Vous le voyez dans les grands projets où de nombreuses branches ont eu un développement indépendant et que tout est prêt à être réuni dans une seule tête.
Une branche de pieuvre fusionne plusieurs têtes en une seule, tant qu'elle peut le faire proprement.
Par exemple, imaginons que votre projet comporte un maître, puis trois branches à fusionner (appelez-les a, b et c).
Voici une série de fusions récursives (notez que la première fusion était une avance rapide, car je n'ai pas forcé la récursion):
Cependant, une seule fusion de poulpe ressemblerait à ceci:
commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...
Les notres
Ours == Je veux tirer une autre tête, mais jette tous les changements que la tête introduit.
Cela conserve l'historique d'une branche sans aucun des effets de la branche.
(Lire: on ne regarde même pas les changements entre ces branches. Les branches sont simplement fusionnées et rien n’est fait pour les fichiers. Si vous voulez fusionner dans l’autre branche et à chaque fois il y a la question "notre version de fichier ou leur version "vous pouvez utiliser git merge -X ours)
Sous-arbre
Le sous-arbre est utile lorsque vous souhaitez fusionner un autre projet dans un sous-répertoire de votre projet actuel. Utile lorsque vous avez une bibliothèque que vous ne souhaitez pas inclure en tant que sous-module.
En fait, les deux seules stratégies que vous voudriez choisir sont la nôtre si vous souhaitez abandonner les modifications apportées par branche, mais conservez la branche dans l'historique, et sous-arbre si vous effectuez une fusion indépendante projet dans le sous-répertoire du superprojet (comme 'git-gui' dans le référentiel 'git').
octopus La fusion est utilisée automatiquement lors de la fusion de plus de deux branches. resol est ici principalement pour des raisons historiques, et lorsque vous êtes touché par récursif fusionner les cas de coin stratégiques.
Stratégie de fusion "Résoudre" vs "Récursive"
Récursif est la stratégie actuelle à deux têtes par défaut, mais après quelques recherches, j'ai finalement trouvé des informations sur la stratégie de fusion "résoudre".
Extrait du livre O'Reilly Contrôle de version avec Git ( Amazon ) (paraphrasé):
A l'origine, "résoudre" était la stratégie par défaut pour les fusions Git.
Dans les situations de fusion croisées, où il y a plus d'une base de fusion possible, la stratégie de résolution fonctionne comme suit: choisissez l'une des bases de fusion possibles et espérez qu'elles seront meilleures. Ce n'est pas aussi grave que ça en a l'air. Il s'avère souvent que les utilisateurs ont travaillé sur différentes parties du code. Dans ce cas, Git détecte qu'il réintègre certaines modifications déjà en place et ignore les modifications en double, évitant ainsi le conflit. Ou, s’il s’agit de légers changements générateurs de conflits, le développeur doit au moins pouvoir les gérer facilement.
J'ai réussi à fusionner des arbres en utilisant "résoudre" qui a échoué avec la stratégie récursive par défaut. J'avais des erreurs fatal: git write-tree failed to write a tree, et grâce à cet article de blog ( miroir ), j'ai essayé "-s resol", ce qui a fonctionné. Je ne suis toujours pas tout à fait sûr de savoir pourquoi ... mais je pense que c'était parce que j'avais des modifications en double dans les deux arbres et que ma résolution les "sautait" correctement.