Quand utiliseriez-vous les différentes stratégies de fusion git?
de la page de manuel sur git-merge, il y a un certain nombre de stratégies de fusion que vous pouvez utiliser.
-
résoudre - Cela ne peut résoudre que deux têtes (i.e. la branche courante et une autre branche à partir de laquelle vous avez tiré) en utilisant l'algorithme de fusion à 3 voies. Il tente de détecter soigneusement les ambiguïtés de fusion criss-cross et est considéré comme généralement sûr et rapide.
-
récursive - Cela ne peut résoudre que deux têtes en utilisant l'algorithme de fusion à trois voies. Quand il y a plus d'un ancêtre commun qui peut être utilisé pour la fusion à 3 voies, il crée un arbre fusionné des ancêtres communs et utilise cela comme arbre de référence pour la fusion à 3 voies. Ceci a été rapporté comme résultant en moins de conflits de fusion sans causer de fausses fusions par des tests faits sur des commit réelles de fusion prises à partir de L'histoire de développement du noyau Linux 2.6. En outre, cela peut détecter et gérer les fusions impliquant renommer. Il s'agit de la stratégie de fusion par défaut lorsque vous tirez ou fusionnez une branche.
-
octopus - Cela résout plus que le cas de deux têtes, mais refuse de faire la fusion complexe qui nécessite une résolution manuelle. Il est principalement destiné à être utilisé pour regrouper les chefs de service de sujet ensemble. Il s'agit de la stratégie de fusion par défaut lorsqu'on tire ou fusionne plusieurs branches.
-
le nôtre - Cela résout n'importe quel nombre de têtes, mais le résultat de la fusion est toujours la tête de la branche courante. Il est destiné à être utilisé pour remplacer l'histoire ancienne de développement des branches latérales.
-
subtree - Il s'agit d'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 de L'arbre de A, au lieu de lire les arbres au même niveau. Ce un ajustement est également fait à l'arbre ancêtre commun.
Quand dois-je spécifier autre chose que la valeur par défaut? Quels sont les scénarios les mieux?
3 réponses
Je ne suis pas familier avec resolve, mais j'ai utilisé les autres:
Récursive
Recursive est la valeur par défaut pour les fusions Non-fast-forward. Nous sommes tous familiers avec celui-là.
Octopus
j'ai utilisé octopus quand j'ai eu plusieurs arbres qui devaient être fusionnés. Vous voyez cela dans les projets plus grands où de nombreuses branches ont eu le développement indépendant et tout est prêt à se réunir dans une seule tête.
une branche de pieuvre fusionne plusieurs têtes en une seule commit tant qu'elle peut le faire proprement.
pour l'illustration, imaginez que vous avez un projet qui a un maître, puis trois branches à fusionner (appelez-les a, b, et c).
une série de fusions récursives ressemblerait à ceci (notez que la première fusion était une avance rapide, comme je n'ai pas forcé la récursion):
cependant, une seule fusion de poulpes ressemblerait à ceci:
commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...
notre
Ours = = je veux tirer dans une autre tête, mais jeter tous les changements que la tête introduit.
Ce qui maintient l'histoire d'une branche sans aucun des effets de la branche.
(lire: ce n'est pas même regardé les changements entre les branches. Les branches sont simplement fusionnées et rien n'est fait aux 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 )
Subtree
Subtree est utile lorsque vous voulez fusionner dans 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 comme un sous-module.
en fait, les deux seules stratégies que vous voudriez choisir sont notre si vous voulez abandonner les changements apportés par la branche, mais garder la branche dans l'histoire, et subtree si vous fusionnez le projet indépendant dans le sous-répertoire de superproject (comme 'git-gui' dans 'git' le dépôt).
octopus fusion est utilisé automatiquement lors de la fusion de plus de deux branches. résoudre est ici principalement pour des raisons historiques, et pour quand vous êtes frappé par recursive coin stratégie de fusion.
"Résoudre" vs "Récursive" fusion "de stratégie de 151920920"
récursive est la stratégie actuelle par défaut à deux têtes, mais après quelques recherches j'ai finalement trouvé quelques informations sur la stratégie de fusion" résoudre".
Prises de O'Reilly livre Contrôle de Version avec Git ( Amazon ) (paraphrase):
à l'Origine, de "résoudre" a été la stratégie par défaut pour Git fusionne.
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 ceci: choisir une des bases de fusion possibles, et espérer le meilleur. C'est vraiment pas aussi mauvais que cela puisse paraître. Il s'avère souvent que les utilisateurs ont travaillé sur les différentes parties du code. Dans ce cas, Git détecte qu'il remerge certains changements qui sont déjà en place et saute les changements en double, en évitant le conflit. Ou, si ceux-ci sont de légers changements cela provoque un conflit, au moins le conflit devrait être facile à gérer pour le développeur..
j'ai fusionné avec succès des arbres en utilisant" resolve " qui a échoué avec la stratégie par défaut récursive. Je recevais fatal: git write-tree failed to write a tree erreurs, et grâce à ce billet de blog ( miroir ) j'ai essayé "-s resolve", qui a fonctionné. Je ne suis toujours pas sûr de savoir exactement pourquoi... mais je pense que c'était parce que j'avais des changements en double dans les deux arbres, et résoudre "sauté".