Ce qui constitue un conflit de fusion dans Git?
Comment git déterminer qu'une fusion a un conflit et le conflit?
Ma conjecture irait quelque chose comme ceci: si les deux commits fusionnés ont un commit parent commun, et s'ils ont tous deux changé la ligne X de ce que le parent avait, c'est un conflit.
Ce qui complique ma compréhension est:
- "changer la ligne X" peut signifier le remplacer par plusieurs nouvelles lignes, et cela est toujours montré comme un conflit (la version A A cette ligne, et la version B a ces 5 lignes, ou autre)
- Si vous insérez des lignes dans l'un des commits, un algorithme plus stupide penserait que toutes les lignes suivantes ont changé: la ligne 30 a maintenant l'ancien contenu de la ligne 25, 31 a l'ancien contenu de 26, etc. Mais git peut dire que ce sont les mêmes, et je ne sais pas comment.
Quelqu'un Peut-il expliquer comment cela fonctionne, ou m'indiquer un lien qui n'?
3 réponses
En fait, avec git, chaque fusion est un conflit, qui vous laisse avec un index qui contient trois versions de chaque fichier, les versions de chaque direction et la base. Sur cet index, différents résolveurs sont exécutés, qui peuvent décider pour chaque fichier individuel comment résoudre le problème.
La première étape est un résolveur trivial, qui prend en charge des choses comme des fichiers inchangés, des cas où une branche a modifié un fichier tandis que l'autre ne l'a pas fait, ou où les deux branches contiennent le même nouvelle version du fichier.
Ensuite, ce sont les plugins qui regardent les cas restants. Il existe un plugin qui gère les fichiers texte en identifiant les modifications individuelles (comme diff) dans une branche et en essayant de les appliquer à l'autre branche, en retombant sur le placement de marqueurs de conflit si cela ne fonctionne pas. Vous pouvez facilement accrocher dans votre propre outil de fusion à ce stade, par exemple, vous pouvez écrire un outil qui sait comment fusionner des fichiers XML sans violer la bonne forme, ou qui donne un interface utilisateur graphique qui permet l'édition interactive et une vue côte à côte (par exemple, KDiff3 fait cela).
Donc, la présentation des conflits est vraiment une question de plugin utilisé; le plugin par défaut pour les fichiers texte utilisera le même style que CVS, parce que les gens et les outils sont habitués, et les marqueurs de conflit sont une erreur de syntaxe connue dans presque n'importe quel langage de programmation.
Je ne pense pas que L'algorithme de fusion ait quelque chose de spécial avec Git: c'est un algorithme de fusion à 3 voies classique (pas celui de Codeville ), qui peut être utilisé avec plusieurs stratégies (par défaut: recurse, ou resolve ou octopus).
Le résultat est un assez simplement le processus de fusion qui décrit ici.
Tout besoin de visualisation est ensuite délégué à des outils de fusion/diff tiers.
Accédez au paragraphe HOW CONFLICTS ARE PRESENTED de cette page .
LE: Il n'y a pas de documentation réelle pour les cas de conflit ni de marqueurs de conflit de fichiers et comme je suis frappé dans les commentaires ici, voici les pointeurs dans le code source qui mènent quelque part près des stratégies que git suit pour atteindre un État de conflit. Fichier fusion-récursive.c , recherchez la chaîne "CONFLICT. Ce faisant nous pouvons facilement découvrir qu'il y a vraiment une poignée de cas de conflit comme:
- conflit (renommer/renommer)
- conflit (contenu)
- conflit (renommer/répertoire)
- conflit (renommer/supprimer)
- conflit (renommer/ajouter)
- conflit (supprimer/modifier)
- ... ans ainsi de suite
Si vous me demandez, oui, ils devraient être documentés et clairement signalés, mais ils ne sont pas si rien à faire alors inspecter la source.. mais quelqu'un peut vraiment ramasser d'ici et créer une belle documentation puis l'envoyer au projet git.
@Wim Coenen Oui, cela dépend aussi des stratégies de fusion, mais la façon dont les conflits sont présentés donne beaucoup plus de perspicacité. Ensuite, vous pouvez lire les stratégies de fusion aussi si vous me demandez, mais vous restez toujours dans le doute.