34 Question: Comment résoudre les conflits de fusion dans Git

question créée à Wed, May 15, 2019 12:00 AM

Comment résoudre les conflits de fusion dans Git?

    
4443
  1. Le billet de blog suivant semble donner un très bon exemple sur la façon de gérer un conflit de fusion avec Git qui devrait vous faire avancer dans la bonne direction. Gestion et prévention des conflits dans Git
    2008-10-02 11: 40: 03Z
  2. Vous pouvez configurer un outil de fusion (kdiff3 jebaird.com/2013/07/08/… ), puis utilisez git mergetool. Lorsque vous travaillez dans de grandes équipes de développeurs, vous rencontrez toujours des conflits de fusion.
    2015-04-18 05: 37: 12Z
  3. N'oubliez pas que vous pouvez atténuer la plupart des conflits de fusion en effectuant régulièrement des fusions en aval!
    2015-07-27 09: 50: 33Z
  4. 2015-10-20 11: 19: 55Z
  5. Question fascinante: posée en 2008, 100% open end ne donnait aucune indication sur ce dont il s'agissait vraiment (s'agit-il d'une interface graphique? des commandes git? de la sémantique?) de pousser /tirer ou juste des conflits généraux?) - complètement irréfutable. 30 réponses, toutes (autant que le montre rapidement) plus ou moins à propos de différents outils de diff3 et de fusion, aucune n'a été acceptée. La réponse la plus votée mentionne une commande qui ne fonctionne même pas avec l'installation git par défaut. J'ai réussi à atteindre la page de démarrage de la SE aujourd'hui, 2017, avec 1,3 million de vues et des milliers de votes dans les deux sens. Fascinant.
    2017-07-11 16: 48: 34Z
30 réponses                              30                         

Essayez: git mergetool

Il ouvre une interface graphique qui vous guide dans chaque conflit et vous permet de choisir le mode de fusion. Parfois, cela nécessite un peu de retouche à la main, mais généralement cela suffit. C’est bien mieux que de tout faire à la main, certainement.

Selon le commentaire de @JoshGlover:

La commande n'ouvre pas nécessairement une interface graphique, sauf si vous en installez une. L'exécution de git mergetool pour moi a abouti à l'utilisation de vimdiff. Vous pouvez également utiliser l'un des outils suivants pour l'utiliser: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Voici l'exemple de procédure à utiliser pour utiliser vimdiff pour résoudre les conflits de fusion. Basé sur ce lien

.

Étape 1 : exécutez les commandes suivantes dans votre terminal

 
git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

Ceci définira vimdiff comme outil de fusion par défaut.

Étape 2 : exécutez la commande suivante dans le terminal

 
git mergetool

Étape 3 : un écran vimdiff au format suivant

 
  ╔═══════╦══════╦════════╗
  ║       ║      ║        ║
  ║ LOCAL ║ BASE ║ REMOTE ║
  ║       ║      ║        ║
  ╠═══════╩══════╩════════╣
  ║                       ║
  ║        MERGED         ║
  ║                       ║
  ╚═══════════════════════╝

Ces 4 vues sont

  

LOCAL - il s’agit du fichier de la branche actuelle

     

BASE - ancêtre commun, à quoi ressemblait le fichier avant les deux modifications

     

REMOTE - fichier que vous fusionnez dans votre branche

     

MERGED - le résultat de la fusion, c'est ce qui est enregistré dans le référentiel

Vous pouvez naviguer entre ces vues en utilisant ctrl + w . Vous pouvez accéder directement à la vue MERGED en utilisant ctrl + w suivi de j .

Plus d'infos sur la navigation vimdiff ici et here

Étape 4 . Vous pouvez modifier la vue MERGED de la manière suivante

Si vous souhaitez obtenir des modifications de REMOTE

 
:diffg RE  

Si vous souhaitez obtenir les modifications de BASE

 
:diffg BA  

Si vous souhaitez obtenir des modifications de LOCAL

 
:diffg LO 

Étape 5 . Enregistrer, quitter, valider et nettoyer

:wqa enregistrer et quitter vi

git commit -m "message"

git clean Supprimer les fichiers supplémentaires (par exemple * .orig) créés par l’outil diff.

    
2662
2019-06-23 15: 50: 52Z
  1. Pour votre information, vous pouvez utiliser git mergetool -y pour enregistrer quelques frappes au clavier si vous fusionnez plusieurs fichiers à la fois.
    2010-06-17 23: 32: 50Z
  2. Eh bien, cela n'ouvre pas nécessairement une interface graphique, sauf si vous en installez une. L'exécution de git mergetool pour moi a abouti à l'utilisation de vimdiff. Vous pouvez également utiliser l'un des outils suivants pour l'utiliser: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis vimdiff emerge.
    2011-05-11 14: 00: 49Z
  3. Bon point Josh. Sur Ubuntu, j’ai eu la meilleure chance avec meld, son affichage de fusion à trois voies n’est pas mauvais. Sur OSX, Git a choisi un joli paramètre par défaut.
    2011-05-24 05: 08: 08Z
  4. Cela a ouvert KDiff3. Ce que je n'ai absolument aucune idée de comment utiliser.
    2011-06-10 18: 46: 25Z
  5. Vous pouvez également utiliser Beyond Compare 3 now (git mergetool -t bc3).
    2012-08-30 14: 59: 24Z

Voici un cas d'utilisation probable, en partant du haut:

Vous allez apporter des modifications, mais oups, vous n'êtes pas à jour:

 
git fetch origin
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

Vous êtes donc à jour et vous essayez à nouveau, mais vous avez un conflit:

 
git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

Vous décidez donc d'examiner les modifications:

 
git mergetool

Oh mon, oh mon, en amont a changé certaines choses, mais juste pour utiliser mes changements ... non ... leurs changements ...

 
git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

Et puis nous essayons une dernière fois

 
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da!

    
1643
2019-06-10 08: 10: 35Z
  1. Cela a été très utile car j'ai eu beaucoup d'erreurs de fusion avec des fichiers binaires (actifs artistiques) et la fusion de ceux-ci semble toujours échouer, je dois donc l'écraser avec le nouveau fichier toujours et non "fusion"
    2011-06-08 17: 39: 40Z
  2. Attention! La signification de --ours et --lesirs est inversée. --ours == la télécommande. --les leurs == local. Voir git merge --help
    2013-03-04 22: 56: 21Z
  3. Dans mon cas, je confirme que --theirs = référentiel distant, --ours = mon propre référentiel local. C'est l'inverse des commentaires @mmell.
    2013-06-22 12: 59: 08Z
  4. @ mmell Seulement sur une base, apparemment. Voir this question
    2013-11-10 06: 19: 14Z
  5. Les gars, "nos" et "leurs" sont relatifs au fait que vous soyez en train de fusionner ou de changer de base. Si vous êtes En fusionnant , "nôtre" signifie la branche dans laquelle vous fusionnez, et "leur" est la branche dans laquelle vous fusionnez. Lorsque vous rebasez , alors "nôtre" signifie les commits sur lesquels vous rebasculez, tandis que "leurs" se rapporte aux commits que vous souhaitez rebasonner.
    2014-05-26 04: 27: 22Z

Je trouve que les outils de fusion ne m'aident que rarement à comprendre le conflit ou larésolution. J'ai généralement plus de succès à regarder les marqueurs de conflit dans un éditeur de texte et à utiliser git log comme complément.

Voici quelques conseils:

Premier conseil

La meilleure chose que j'ai trouvée est d'utiliser le style de conflit de fusion "diff3":

git config merge.conflictstyle diff3

Ceci produit des marqueurs de conflit comme ceci:

 
<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

La section du milieu représente l’ancêtre commun. Ceci est utile car vous pouvez le comparer aux versions supérieure et inférieure pour avoir une meilleure idée de ce qui a été modifié sur chaque branche, ce qui vous donne une meilleure idée de l'objectif de chaque modification.

Si le conflit ne comporte que quelques lignes, cela le rend généralement très évident. (Savoir résoudre un conflit est très différent; vous devez savoir ce sur quoi les autres personnes travaillent. Si vous êtes confus, il est probablement préférable d'appeler cette personne dans votre chambre pour qu'elle voie ce que vous cherchez. at.)

Si le conflit est plus long, je vais couper et coller chacune des trois sections dans trois fichiers distincts, tels que "mine", "commun" et "leur".

Ensuite, je peux exécuter les commandes suivantes pour voir les deux mecs diff qui ont provoqué le conflit:

 
diff common mine
diff common theirs

Ce n’est pas la même chose que d’utiliser un outil de fusion, puisqu'un outil de fusion inclura également tous les mecs diff non conflictuels. Je trouve cela distrayant.

Astuce deux

Quelqu'un a déjà mentionné cela, mais comprendre l’intention qui se cache derrière chaque bloc diff est généralement très utile pour comprendre l’origine d’un conflit et la façon de le gérer.

 
git log --merge -p <name of file>

Ceci affiche tous les commits qui ont touché ce fichier entre l’ancêtre commun et les deux têtes que vous fusionnez. (Cela n'inclut donc pas les commits qui existaient déjà dans les deux branches avant la fusion.) Cela vous aide à ignorer les diffs qui ne sont clairement pas un facteur dans votre conflit actuel.

Troisième conseil

Vérifiez vos modifications avec des outils automatisés.

Si vous avez des tests automatisés, lancez-les. Si vous possédez une lint , exécutez-la. S'il s'agit d'un projet pouvant être construit, construisez-le avant de le valider, etc. Dans tous les cas, vous devez effectuer quelques tests pour vous assurer que vos modifications ne brisent rien. (Heck, même une fusion sans conflits peut casser le code qui fonctionne.)

Quatrième conseil

Planifiez à l'avance; communiquer avec des collègues.

Planifier à l’avance et être au courant des réalisations des autres peut aider à prévenir les conflits de fusion et /ou à les résoudre plus tôt - tout en gardant à l’esprit les détails.

Par exemple, si vous savez que vous et une autre personne travaillez sur un refactoring différent qui affectera le même ensemble de fichiers, vous devez vous parler à l'avance et avoir une idée plus précise des types de modifications que chacun d'eux apporte. de vous fait. Vous économiserez peut-être beaucoup de temps et d'efforts si vous effectuez les modifications planifiées en série plutôt qu'en parallèle.

Pour les refactorisations majeures couvrant une grande partie du code, envisagez sérieusement de travailler en série: tout le monde cesse de travailler sur cette partie du code pendant qu'une personne effectue la refactorisation complète.

Si vous ne pouvez pas travailler en série (peut-être pour des raisons de temps), la communication sur les conflits de fusion attendus vous aide au moins à résoudre les problèmes plus tôt, tout en gardant à l'esprit les détails. Par exemple, si un collègue effectue une série de commissions perturbatrices au cours d'une période d'une semaine, vous pouvez choisir de fusionner /rebaser sur cette branche de collègues une ou deux fois par jour au cours de cette semaine. Ainsi, si vous trouvez des conflits de fusion /refonte, vous pouvez les résoudre plus rapidement que si vous attendez quelques semaines pour tout fusionner en un seul bloc.

Astuce cinq

Si vous n'êtes pas sûr d'une fusion, ne forcez pas.

La fusion peut sembler fastidieuse, en particulier lorsque de nombreux fichiers sont en conflit et que les marqueurs de conflit couvrent des centaines de lignes. Souvent, lors de l’estimation de projets logiciels, nous ne prenons pas assez de temps pour des éléments tels que la gestion d’une fusion épineuse, il est donc difficile de passer plusieurs heures à disséquer chaque conflit.

À long terme, planifier et anticiper les éléments sur lesquels les autres travaillent sont les meilleurs outils pour anticiper les conflits de fusion et se préparer à les résoudre correctement en moins de temps.

    
710
2014-07-23 17: 32: 54Z
  1. L'option diff3 est une fonctionnalité intéressante à avoir avec les fusions. La seule interface graphique que je connaisse qui montre que c’est le p4merge de Perforce, qui peut être installée et utilisée séparément des autres outils de Perforce (que je n’ai pas utilisée, mais que j'ai entendu se plaindre).
    2014-05-01 22: 15: 41Z
  2. Après une tentative de refonte de la base ayant entraîné un conflit de fusion: $git log --merge -p build.xml sortie: fatal: --merge sans MERGE_HEAD?
    2016-06-17 09: 15: 07Z
  3. Et si j'ai des modifications sur un fichier de branch1 et la suppression de ce fichier dans branch2. Comment puis-je résoudre ce conflit de fusion? Existe-t-il un moyen d'utiliser git où je peux les fusionner en conservant les modifications d'une branche?
    2017-01-21 14: 48: 16Z
  4. git config merge.conflictstyle diff3 - merci, monsieur. Ceci est incroyable et m'a libéré d'essayer de trouver (et payer $$) une bonne interface graphique de fusion à 3 voies. IMO, c’est mieux car cela montre l’ancêtre commun ainsi que local /distant, et indiquent les dernières lignes de journal de validation, ce que (autant que je sache) aucune interface graphique ne le permet. Les commits vous aident certainement à identifier quel code appartient à quelle branche.
    2017-04-04 16: 00: 53Z
  5. J'ai constaté que parfois le style de conflit diff3 donnait lieu à d'énormes énormes différences qui étaient en grande partie identiques, alors que la valeur par défaut produirait des éléments plus petits et plus faciles à gérer. Malheureusement, je n'ai pas de reproducteur que je puisse utiliser pour un rapport de bogue. Toutefois, si vous rencontrez ce problème, vous pouvez éventuellement désactiver cette option.
    2017-07-02 03: 31: 12Z
  1. Identifiez les fichiers en conflit (Git devrait vous l'indiquer).

  2. Ouvrez chaque fichier et examinez les diffs; Git les démarque. Espérons que la version de chaque bloc à conserver sera évidente. Vous devrez peut-être en discuter avec les autres développeurs qui ont validé le code.

  3. Une fois que vous avez résolu le conflit dans un fichier git add the_file.

  4. Une fois que vous avez résolu tous les conflits, exécutez la commande git rebase --continue ou une commande quelconque. Git a dit de faire quand vous avez terminé.

333
2014-08-07 17: 48: 46Z
  1. @ Justin Pensez à Git comme moyen de suivi du contenu plutôt que du suivi des fichiers. Il est alors facile de constater que le contenu que vous avez mis à jour ne se trouve pas dans le référentiel et doit être ajouté. Cette façon de penser explique également pourquoi Git ne suit pas les dossiers vides: bien qu’il s’agisse techniquement de fichiers, il n’ya pas de contenu à suivre.
    2010-10-12 09: 17: 27Z
  2. le contenu est présent, un conflit se produit car il existe 2 versions du contenu. Par conséquent, "git add" ne sonne pas correctement. Et cela ne fonctionne pas (git add, git commit) si vous souhaitez ne valider que le fichier après que le conflit a été résolu ("fatal: impossible d'effectuer une validation partielle lors d'une fusion.")
    2011-09-14 09: 19: 10Z
  3. Oui, techniquement, cela répond à la question qui a été posée, mais qui n’est pas une réponse utilisable, à mon avis, désolé. Quel est le point de rendre une branche identique à une autre? Bien sûr, une fusion aura des conflits ..
    2012-08-09 05: 56: 27Z
  4. Thulfir: qui a dit quoi que ce soit à propos de la création d'une branche identique à une autre? Il existe différents scénarios dans lesquels vous devez fusionner sans "faire en sorte qu'une branche soit identique à une autre". Le premier est lorsque vous avez terminé avec une branche de développement et que vous souhaitez incorporer ses modifications dans la branche principale; après cela, la branche de développement peut être supprimée. Une autre possibilité est de vouloir rebaser votre branche de développement afin de faciliter la fusion finale avec le maître.
    2012-09-21 08: 50: 19Z
  5. @ JustinGrant git add place les fichiers dans l'index; rien n’ajoute rien au référentiel. git commit ajoute des éléments au référentiel. Cette utilisation est logique pour les fusions - la fusion se fait automatiquementtoutes les modifications pouvant être fusionnées automatiquement; il est de votre responsabilité de fusionner le reste des modifications et de les ajouter à l'index lorsque vous avez terminé.
    2012-10-17 15: 13: 05Z

Consultez les réponses dans la question relative au débordement de la pile Annulation d'une fusion dans Git , en particulier la réponse de Charles Bailey qui montre comment afficher les différentes versions du fichier avec des problèmes, par exemple,

 
# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp
    
102
2017-05-23 11: 47: 34Z
  1. Découvrez également l'option "-m" de "git checkout -m" - elle vous permet d'extraire les différentes mouches dans votre espace de travail
    2015-02-05 22: 06: 41Z
  2. Cela m'a sauvé. Regarder chaque fichier séparément m'a permis de me rappeler ce que je cherchais dans chaque branche. Ensuite, je pourrais prendre la décision de choisir.
    2016-05-14 21: 59: 15Z

Les conflits de fusion se produisent lorsque des modifications sont apportées à un fichier en même temps. Voici comment le résoudre.

 git CLI

Voici quelques étapes simples à suivre en cas de conflit:

  1. Notez la liste des fichiers en conflit avec: git status (sous la section Unmerged paths).
  2. Résolvez les conflits séparément pour chaque fichier en appliquant l'une des approches suivantes:

    • Utilisez l'interface graphique pour résoudre les conflits: git mergetool (le moyen le plus simple).

    • Pour accepter la version distante /autre, utilisez: git checkout --theirs path/file. Cela rejettera toutes les modifications locales apportées à ce fichier.

    • Pour accepter la version locale /notre, utilisez: git checkout --ours path/file

      Cependant, vous devez faire attention, car des modifications à distance ont été apportées à des conflits pour une raison quelconque.

      En relation: Quel est le sens exact de "our" et "leurs" dans git?

    • Editez les fichiers en conflit manuellement et cherchez le bloc de code compris entre <<<<</>>>>>, puis choisissez la version ci-dessus ou ci-dessous =====. Voir: présentation des conflits .

    • Les conflits de chemins et de noms de fichiers peuvent être résolus en git add/git rm.

  3. Enfin, examinez les fichiers prêts pour la validation en utilisant: git status.

    Si vous avez toujours des fichiers inférieurs à Unmerged paths et que vous avez résolu le conflit manuellement, faites savoir à Git que vous l'avez résolu par: git add path/file.

  4. Si tous les conflits ont été résolus avec succès, validez les modifications par: git commit -a et transmettez les modifications à distance comme d'habitude.

Voir aussi: Résolution d'un conflit de fusion depuis la ligne de commande sur GitHub

DiffMerge

J'ai utilisé avec succès DiffMerge , qui permet de comparer et de fusionner de manière visuelle des fichiers sous Windows, MacOS et Linux /Unix. .

Il peut afficher graphiquement les modifications entre 3 fichiers et permet la fusion automatique (lorsque cela ne présente aucun danger) et un contrôle total sur la modification du fichier résultant.

 DiffMerge

Source de l'image: DiffMerge (capture d'écran Linux)

Téléchargez-le simplement et exécutez-le dans le dépôt en tant que:

 
git mergetool -t diffmerge .

macOS

Sur macOS, vous pouvez installer via:

 
brew install caskroom/cask/brew-cask
brew cask install diffmerge

Et probablement (si non fourni) vous avez besoin du wrapper extra-simple suivant placé dans votre PATH (par exemple /usr/bin):

 
#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$@"

Ensuite, vous pouvez utiliser les raccourcis clavier suivants:

  • - Alt - Haut / Bas pour passer aux modifications précédentes /suivantes.
  • - Alt - gauche / droite pour accepter les modifications de gauche ou de droite

Vous pouvez également utiliser opendiff (partie de Xcode Tools) permettant de fusionner deux fichiers ou répertoires pour créer un troisième fichier ou répertoire.

    
90
2017-05-23 10: 31: 39Z

Si vous effectuez de petits commits fréquents, commencez par examiner les commentaires de commits avec git log --merge. Ensuite, git diff vous montrera les conflits.

Pour les conflits comportant plus de quelques lignes, il est plus facile de voir ce qui se passe dans un outil graphique externe. J'aime opendiff - Git prend également en charge vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, sortent de la boîte et vous pouvez en installer d’autres: git config merge.tool "your.tool" définira l’outil choisi, puis git mergetool après une fusion infructueuse, qui vous montrera les différences contexte.

Chaque fois que vous éditez un fichier pour résoudre un conflit, git add filename met à jour l'index et votre diff ne l'affiche plus. Lorsque tous les conflits sont traités et que leurs fichiers ont été git add -ed, git commit terminera votre fusion.

    
76
2014-07-23 17: 43: 21Z
  1. Utiliser "git add" est le vrai truc ici. Vous ne voulez peut-être même pas vous engager (peut-être que vous voulez cacher), mais vous devez faire "git add" pour terminer la fusion. Je pense que mergetool effectue l’ajout pour vous (bien que ce ne soit pas dans la page de manuel), mais si vous effectuez la fusion manuellement, vous devez utiliser "git add" pour le compléter (même si vous ne voulez pas valider).
    2010-10-25 09: 37: 00Z

Voir présentation des conflits ou, dans Git , la documentation git merge pour comprendre ce que sont les marqueurs de conflit de fusion.

La section Comment résoudre les conflits explique comment résoudre les conflits:

  

Après avoir vu un conflit, vous pouvez faire deux choses:

     
  • Décidez de ne pas fusionner. Les seuls nettoyages dont vous avez besoin sont de réinitialiser le fichier d'index sur le commettre HEAD pour inverser 2. et de nettoyer les modifications apportées à l'arbre de travail effectuées par les 2. et 3 .; git merge --abort peut être utilisé pour cela.

  •   
  • Résolvez les conflits. Git marquera les conflits dans l’arbre de travail. Editez les fichiers en forme et git add les dans l'index. Utilisez git commit pour sceller l’accord.

  •   

Vous pouvez résoudre le conflit avec plusieurs outils:

     
  • Utilisez un outil mergetool. git mergetool pour lancer un outil de fusion graphique qui vous aidera à effectuer la fusion.

  •   
  • Regardez les diffs. git diff affichera un diff à trois voies, soulignant les modifications des versions HEAD et MERGE_HEAD.

  •   
  • Regardez les différences de chaque branche. git log --merge -p <path> affichera d'abord les différences pour la version HEAD, puis la version MERGE_HEAD.

  •   
  • Regardez les originaux. git show :1:filename représente l'ancêtre commun, git show :2:filename la version HEAD et git show :3:filename la version MERGE_HEAD.

  •   

Vous pouvez également en savoir plus sur les marqueurs de conflit de fusion et sur la façon de les résoudre dans la section de livre de Pro Git Conflits de fusion élémentaires .

    
44
2014-07-23 17: 22: 15Z

Pour les Emacs utilisateurs qui souhaitent résoudre les conflits de fusion de manière semi-manuelle:

 
git diff --name-status --diff-filter=U

affiche tous les fichiers nécessitant une résolution de conflit.

Ouvrez chacun de ces fichiers un par un ou tous en même temps par:

 
emacs $(git diff --name-only --diff-filter=U)

Lors de la visite d'un tampon nécessitant des modifications dans Emacs, tapez

 
ALT+x vc-resolve-conflicts

Ceci ouvrira trois tampons (le mien, le leur et le tampon de sortie). Naviguez en appuyant sur 'n' (région suivante), 'p' (région de prévision). Appuyez sur 'a' et 'b' pour copier le mien ou sa région dans la sortietampon, respectivement. Et /ou éditez directement le tampon de sortie.

Une fois terminé: Appuyez sur 'q'. Emacs vous demande si vous voulez sauvegarder ce tampon: oui. Une fois la mémoire tampon terminée, marquez-la comme résolue en exécutant à partir du code criminel:

 
git add FILENAME

Lorsque vous avez terminé avec tous les types de tampons

 
git commit

pour terminer la fusion.

    
38
2014-07-23 17: 24: 52Z

Je veux soit ma version ou la version intégrale, soit revoir les modifications individuelles et décider de chacune d'entre elles.

Acceptez pleinement ma version ou la leur :

Accepter ma version (locale, la nôtre):

 
git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

Acceptez leur version (distante, la leur):

 
git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

Si vous souhaitez exécuter tous les fichiers en conflit , exécutez:

.  
git merge --strategy-option ours

ou

 
git merge --strategy-option theirs

Consultez toutes les modifications et acceptez-les individuellement

  1. git mergetool
  2. Consultez les modifications et acceptez l'une ou l'autre version pour chacune d'entre elles.
  3. git add <filename>
  4. git commit -m "merged bla bla"

mergetool par défaut fonctionne en ligne de commande . L’utilisation d’un outil de fusion en ligne de commande doit faire l’objet d’une question distincte.

Vous pouvez également installer un outil visuel à cette fin, par exemple. meld et exécutez

 
git mergetool -t meld

Il ouvrira la version locale (la nôtre), la version "de base" ou "fusionnée" (le résultat actuel de la fusion) et la version distante (la leur). Enregistrez la version fusionnée lorsque vous avez terminé, relancez git mergetool -t meld jusqu'à ce que vous obteniez le message "Aucun fichier à fusionner", puis passez aux étapes 3 et 4.

    
35
2018-06-19 03: 29: 48Z
  1. Cette commande: git checkout --theirs - < nom de fichier > a modifié TOUS les fichiers en leurs fichiers, pas seulement < nom de fichier >
    2018-06-26 01: 00: 29Z
  2. En fait, je me suis trompé. Ceci ne met à jour que le fichier spécifié.
    2018-06-26 01: 23: 15Z

Veuillez suivre les étapes suivantes pour résoudre les conflits de fusion dans Git:

  1. Vérifiez l'état de Git: statut git

  2. Obtenir le patchset: Git Fetch (vérifiez le correctif correct depuis votre commit Git)

  3. Commander une branche locale (temp1 dans mon exemple ici): git checkout -b temp1

  4. Extrait le contenu récent du maître: git pull - maître d'origine d'origine

  5. Démarrez l'outil mergetool, vérifiez les conflits et corrigez-les ... et vérifiez les modifications apportées à la branche distante avec votre branche actuelle: git mergetool

  6. Vérifiez à nouveau l'état:   statut git

  7. Supprimez les fichiers indésirables créés localement par mergetool. En règle générale, mergetool crée un fichier supplémentaire avec l'extension * .orig. Supprimez ce fichier car il ne s'agit que du doublon, corrigez les modifications localement et ajoutez la version appropriée de vos fichiers. git add #your_changed_correct_files

  8. Vérifiez à nouveau l'état: statut git

  9. Valider les modifications sur le même identifiant de validation (cela évite un nouveau jeu de correctifs séparé): git commit --amend

  10. Push vers la branche principale: Git Push (vers votre référentiel Git)

28
2018-06-19 03: 25: 07Z

Simplement, si vous savez bien que les modifications dans l'un des référentiels ne sont pas importantes et souhaitez résoudre toutes les modifications en faveur de l'autre, utilisez:

 
git checkout . --ours

pour résoudre les modifications en faveur de votre référentiel ou

 
git checkout . --theirs

pour résoudre les modifications en faveur de autre ou du référentiel principal .

Sinon, vous devrez utiliser un outil de fusion d'interface graphique pour parcourir les fichiers un par un. Supposons que cet outil de fusion porte le numéro p4merge ou d'écrire le nom de votre choix.

 
git mergetool -t p4merge

et après avoir terminé un fichier, vous devrez enregistrer et fermer le fichier suivant. Le suivant s'ouvre.

    
28
2018-06-19 03: 26: 09Z
  1. git checkout. --les leurs ont résolu mon problème grâce
    2016-03-10 06: 53: 00Z
  2. si vous préférez résoudre les conflits manuellement, essayez d'ouvrir le dossier dans Visual Studio Code, cela marque les fichiers avec des conflits et des lignes de conflit de couleurs à l'intérieur de chaque
    2016-07-03 08: 31: 42Z

Bonus:

En parlant de pull /fetch /fusion dans les réponses ci-dessus, je voudrais partager un tour intéressant et productif,

git pull --rebase

Cette commande ci-dessus est la commande la plus utile de ma vie, qui a permis de gagner beaucoup de temps.

Avant de transférer votre modification récemment validée sur le serveur distant, essayez git pull --rebase plutôt que git pull et le manuel merge; il synchronisera automatiquement les dernières modifications du serveur distant (avec une opération extraction + fusion) et placera votre dernière validation locale en haut dans le journal git. Pas besoin de s'inquiéter de l'extraction /fusion manuelle.

En cas de conflit, utilisez simplement

 
git mergetool
git add conflict_file
git rebase --continue

Vous trouverez les détails sur: http://gitolite.com/git-pull--rebase

    
27
2015-12-31 03: 30: 19Z

Vous pouvez résoudre les conflits de fusion de différentes manières, comme d'autres l'ont expliqué.

Je pense que la vraie clé est de savoir comment les changements se déroulent avec les référentiels locaux et distants. La clé est la compréhension des branches de suivi. J'ai constaté que je considérais la branche de suivi comme la "pièce manquante au milieu" entre mon répertoire de fichiers local et réel et la télécommande définie comme étant l'origine.

J'ai personnellement pris l'habitude de 2 choses pour éviter cela.

Au lieu de:

 
git add .
git commit -m"some msg"

Ce qui présente deux inconvénients -

a) Tous les fichiers nouveaux /modifiés sont ajoutés et peuvent inclure des modifications indésirables.
b) Vous ne devez pas d'abord consulter la liste des fichiers.

Je préfère donc:

 
git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

De cette façon, vous décidez plus facilement des fichiers à ajouter, vous pouvez également consulter la liste et réfléchir un peu plus lorsque vous utilisez l'éditeur pour le message. Je trouve que cela améliore également mes messages de commit lorsque j'utilise un éditeur plein écran plutôt que l'option -m.

[Mise à jour - au fil du temps, je suis passé à:

 
git status # Make sure I know whats going on
git add .
git commit # Then use the editor

]

Aussi (et plus pertinent pour votre situation), j'essaie d'éviter:

 
git pull

ou

 
git pull origin master.

Parce que tirer implique une fusion et si vous avez des modifications que vous ne voulez pas fusionner localement, vous pouvez facilement vous retrouver avec un code fusionné et /ou des conflits de fusion pour du code qui n'aurait pas dû l'être.

J'essaie plutôt de faire

 
git checkout master
git fetch   
git rebase --hard origin/master # or whatever branch I want.

Vous pouvez également trouver cela utile:

git branche, fork, chercher, fusionner, rebaser et cloner, quelles sont les différences?

    
25
2017-05-23 12: 18: 27Z
  1. Hé, j'ai un peu compris votre réponse. Mais comme je suis nouveau dans le github, je pense qu'il manque quelque chose. Qu'advient-il de vos modifications locales lorsque vous effectuez git checkout master et git fetch et git rebase --hard origin/master
    2017-08-08 17: 43: 36Z
  2. Je pense que vous devriez ajouter plus de détails sur ce qu'il faut faire. Un autre exemple qui me confond, vous avez mentionné dans votre réponse: nous faisons git add ., cela sauvegardera-t-il nos modifications locales afin que nous puissions faire un suivi avec git checkout master? ou sont-ils deux scénarios différents?
    2017-08-08 17: 47: 14Z

Il y a 3 étapes:

  1. Recherchez les fichiers à l'origine des conflits à l'aide de la commande

     
    git status
    
  2. Vérifiez les fichiers dans lesquels vous trouverez les conflits marqués comme

     
    <<<<<<<<head
    blablabla
    
  3. Modifiez-le comme vous le souhaitez, puis validez-le avec des commandes

     
    git add solved_conflicts_files
    git commit -m 'merge msg'
    
25
2018-07-05 21: 03: 45Z
  1. a fonctionné pour moi! Merci!
    2017-09-18 04: 00: 54Z
  2. Vous devez faire attention si vous le faites pendant la refonte. Vous devez utiliser git rebase --continue au lieu de git commit
    .
    2018-10-29 13: 37: 48Z

La réponse de CoolAJ86 résume à peu près tout. Si vous avez des modifications dans les deux branches du même code, vous devrez procéder à une fusion manuelle. Ouvrez le fichier en conflit dans n’importe quel éditeur de texte et vous devriez voir la structure suivante.

 
(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too    
<<<<<<<<<<<
(Code not in conflict here)

Choisissez l'une des alternatives ou une combinaison des deux de la manière que vous souhaitez utiliser pour un nouveau code, tout en supprimant les signes égaux et les crochets angulaires.

 
git commit -a -m "commit message"
git push origin master
    
22
2014-07-23 17: 17: 38Z
 
git log --merge -p [[--] path]

Ne semble pas toujours fonctionner pour moi et finit généralement par afficher chaque commit qui était différent entre les deux branches. Ceci se produit même lorsque -- est utilisé pour séparer le chemin de la commande.

Ce que je fais pour contourner ce problème, c’est ouvrir deux lignes de commande et en une fois

.  
git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

et dans l'autre

 
git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

Remplacement de $MERGED_IN_BRANCH par la branche dans laquelle j'ai fusionné et [path] par le fichier en conflit. Cette commande enregistre tous les commits, sous forme de correctif, entre (..) deux commets. Si vous laissez un côté vide, comme dans les commandes ci-dessus, git utilisera automatiquement HEAD (la branche dans laquelle vous fusionnez dans ce cas).

Cela vous permettra de voir quels commits sont entrés dans le fichier dans les deux branches après leur divergence. Cela facilite généralement beaucoup la résolution des conflits.

    
15
2016-01-05 03: 45: 43Z

À partir du 12 décembre 2016, vous pouvez fusionner des branches et résoudre les conflits sur github.com

.

Ainsi, si vous ne souhaitez pas utiliser la ligne de commande ou les outils tiers proposés ici à partir d'anciennes réponses , utilisez l'outil natif de GitHub.

Ce billet de blog explique en détail, mais L'essentiel est que lors de la "fusion" de deux branches via l'interface utilisateur, vous verrez maintenant une option "résoudre les conflits" qui vous mènera à un éditeur vous permettant de gérer ces conflits de fusion.

 entrez la description de l'image ici

    
15
2017-01-09 19: 57: 14Z
  1. ceci ne pose pas de question sur github, j'ai donc voté contre ce que j'estime être une très mauvaise réponse.
    2017-01-25 05: 06: 51Z
  2. merci de me garder en échec, mec.
    2017-01-26 23: 07: 24Z
  3. @ mschuett a raison, la question est "comment résoudre les conflits dans git", pas "comment résoudre les conflits dans github". Il y a une différence et il y a déjà beaucoup trop de gens qui pensent que git et github sont la même chose,de sorte que tout ce qui propage ce sentiment est faux.
    2018-04-05 16: 21: 56Z

Utilisation de patience

Je suis surpris que personne d'autre n'ait parlé de la résolution de conflit à l'aide de patience avec la stratégie de fusion récursive. Pour un grand conflit de fusion, utiliser patience a donné de bons résultats pour moi. L’idée est d’essayer de faire correspondre des blocs plutôt que des lignes individuelles.

Si vous modifiez l'indentation de votre programme par exemple, la stratégie de fusion par défaut de Git correspond parfois à une seule accolade { qui appartient à différentes fonctions. Ceci est évité avec patience:

 
git merge -s recursive -X patience other-branch

À partir de la documentation:

 
With this option, merge-recursive spends a little extra time to avoid 
mismerges that sometimes occur due to unimportant matching lines 
(e.g., braces from distinct functions). Use this when the branches to 
be merged have diverged wildly.

Comparaison avec l'ancêtre commun

Si vous avez un conflit de fusion et souhaitez voir ce que les autres avaient à l’esprit lors de la modification de leur branche, il est parfois plus facile de comparer directement leur branche à l’ancêtre commun (au lieu de notre branche). Pour cela, vous pouvez utiliser merge-base:

 
git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

Généralement, vous souhaitez uniquement voir les modifications apportées à un fichier particulier:

 
git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>
    
15
2018-06-19 03: 31: 39Z
  1. Dans mon cas, cela n'a pas bien résolu les conflits de fusion car, pour une raison quelconque, les lignes de configuration en double étaient conservées dans les projets C #. Bien que ce fût plus convivial que tout le fichier est différent, ce que j’avais auparavant
    2017-09-08 07: 55: 23Z

Je suis toujours les étapes ci-dessous pour éviter les conflits.

  • maître de caisse git (venir à la branche principale)
  • git pull (Mettez à jour votre maître pour obtenir le dernier code)
  • git checkout -b mybranch (Commander une nouvelle branche et commencer à travailler sur cette branche afin que votre maître reste toujours en haut du tronc.)
  • git add. AND git commit AND git push (sur votre branche locale après vos modifications)
  • git checkout master (revenez à votre maître.)

Maintenant, vous pouvez faire la même chose, gérer autant d’agences locales que vous le souhaitez et travailler simultanément tout en effectuant un paiement direct dans votre agence lorsque cela est nécessaire.

    
12
2015-02-12 04: 25: 58Z

Si vous souhaitez fusionner d'une branche (test) à un maître, procédez comme suit:

Étape 1: accédez à la branche

 
git checkout test

Étape 2: git pull --rebase origin master

Étape 3: en cas de conflit, accédez à ces fichiers pour le modifier.

Étape 4: ajoutez ces modifications

 
git add #your_changes_files

Étape 5: git rebase --continue

Étape 6: si le conflit persiste, revenez à l’étape 3. S'il n'y a pas de conflit, procédez comme suit: git push origin +test

Étape 7: Et puis il n’ya pas de conflit entre test et master. Vous pouvez utiliser la fusion directement.

    
11
2018-06-19 03: 23: 34Z

Des conflits de fusion peuvent se produire dans différentes situations:

  • Lorsque vous exécutez "git fetch" puis "git merge"
  • Lorsque vous exécutez "git fetch" puis "git rebase"
  • Lors de l'exécution de "git pull" (ce qui correspond à l'une des conditions susmentionnées)
  • Lors de l'exécution de "git stash pop"
  • Lorsque vous appliquez des correctifs git (les validations exportées vers des fichiers à transférer, par exemple par courrier électronique)

Vous devez installer un outil de fusion compatible avec Git pour résoudre les conflits. Personnellement, j'utilise KDiff3 et je l'ai trouvé agréable et pratique. Vous pouvez télécharger sa version Windows ici:

https://sourceforge.net/projects/kdiff3/files/

BTW si vous installez Git Extensions, l’assistant d’installation contient une option pour installer Kdiff3.

Ensuite, configurez git configs pour utiliser Kdiff comme outil de fusion:

 
$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false

$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

(N'oubliez pas de remplacer le chemin par le chemin du fichier exe Kdiff.)

Thfr chaque fois que vous rencontrez un conflit de fusion, il vous suffit d’exécuter cette commande:

 
$git mergetool

Ensuite, il ouvre Kdiff3 et tente d’abord de résoudre automatiquement les conflits de fusion. La plupart des conflits seraient résolus spontanément et vous devrez régler le reste manuellement.

Voici à quoi ressemble Kdiff3:

 Entrez la description de l'image ici

Ensuite, une fois que vous avez terminé, enregistrez le fichier. Le fichier suivant est traité en conflit et vous répétez la même chose jusqu'à ce que tous les conflits soient résolus.

Pour vérifier si tout est fusionné avec succès, exécutez simplement à nouveau la commande mergetool, vous devriez obtenir le résultat suivant:

 
$git mergetool
No files need merging
    
11
2018-06-19 03: 28: 18Z

Cela répond en ajoutant une alternative aux utilisateurs de VIM comme I qui préfère tout faire dans l'éditeur.

TL; DR

 entrer la description de l'image ici

Tpope a créé ce plug-in pour VIM appelé fugitif . Une fois installé, vous pouvez exécuter :Gstatus pour vérifier les fichiers en conflit et :Gdiff pour ouvrir Git de 3 manières différentes.

Une fois dans la fusion à trois, fugitif vous permettra d’obtenir les modifications de toutes les branches que vous fusionnez de la manière suivante:

  •  :diffget //2, obtenir les modifications de la branche d'origine ( HEAD ):
  •  :diffget //3, obtenir les modifications de la branche fusionnée:

Une fois la fusion du fichier terminée, tapez :Gwrite dans la mémoire tampon fusionnée. Vimcasts a publié une excellente vidéo expliquant en détail cette étapes.

    
7
2018-05-10 11: 45: 24Z
  

git fetch
  Git Checkout votre branche
  maître git rebase

Dans cette étape, vous allez essayer de résoudre le conflit en utilisant votre IDE préféré.

Vous pouvez suivre ce lien pour vérifier comment résoudre le conflit dans le fichier
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/

  

git add
  git rebase --continue
  git commit --amend
  git push HEAD: refs /drafts /master (poussez comme un brouillon)

Maintenant tout va bien et vous trouverez votre commit dans gerrit

J'espère que cela aidera tout le monde à résoudre ce problème.

    
4
2017-07-05 13: 25: 30Z

Gitlense For VS Code

Vous pouvez essayer Gitlense pour le code VS. Leurs principales caractéristiques sont les suivantes:

3. Résolvez facilement les conflits.

J'aime déjà cette fonctionnalité:

 entrer la description de l'image ici

2. Blame de la ligne actuelle.

 entrer la description de l'image ici

3. Gouttière Blame

 entrer la description de l'image ici

4. Blame de la barre d'état

 entrer la description de l'image ici

Il existe de nombreuses fonctionnalités que vous pouvez vérifier ici .

    
4
2019-01-05 18: 33: 46Z

Essayez d’éditer le code Visual Studio si vous ne l’êtes pas déjà. Ce que cela fait, c’est après que vous avez essayé de fusionner (et d’avoir des conflits de fusion). Le code .VS détecte automatiquement les conflits de fusion.

Cela peut vous aider très bien en montrant quelles sont les modifications apportées à l'original et si vous acceptez incoming ou

current change (signifiant l'original avant la fusion) '?.

Cela a aidé pour moi et peut aussi fonctionner pour vous!

PS: Cela ne fonctionnera que si vous avez configuré git avec votre code et le code Visual Studio.

    
2
2018-03-16 06: 26: 08Z

Pour résoudre les conflits de manière plus sûre, utilisez git-mediate (les solutions courantes suggérées). ici, je suis assez sujette à erreur imho).

Voir cet article pour une introduction rapide sur son utilisation.

    
1
2016-12-29 16: 46: 35Z

Pour ceux qui utilisent Visual Studio (2015 dans mon cas)

  1. Fermez votre projet dans VS. Surtout dans les grands projets, VS a tendance à paniquer lors de la fusion à l'aide de l'interface utilisateur.

  2. Effectuez la fusion dans l'invite de commande.

    git checkout target_branch

    git merge source_branch

  3. Ouvrez ensuite le projet dans VS et accédez à Team Explorer - > Branche. À présent, un message indique que la fusion est en attente et que les fichiers en conflit sont répertoriés sous le message.

  4. Cliquez sur le fichier en conflit pour avoir la possibilité de fusionner, comparer, prendre la source, prendre la cible. L’outil de fusion dans VS est très facile à utiliser.

1
2017-07-10 20: 29: 53Z
  1. J'utilise VS Code 2017 sur un très grand projet et je n'ai pas besoin de fermer le projet. Il le gère très bien:)
    2017-08-10 16: 22: 46Z

Si vous utilisez intelliJ comme IDE Essayez de fusionner le parent de votre branche en

 
git checkout <localbranch>
git merge origin/<remotebranch>

Cela montrera tous les conflits comme celui-ci

  

A_MBPro: teste l'origine de la fusion $git /fusion automatique   src /test /java /com /.../TestClass.java CONFLICT   (contenu): Fusionner le conflit dans   src /test /java /com /.../TestClass.java

Notez maintenant que le fichier TestClass.java est affiché en rouge dans intelliJ Le statut de git affichera également

 
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   src/test/java/com/.../TestClass.java

Ouvrez le fichier dans intelliJ, il comportera des sections avec

 
  <<<<<<< HEAD
    public void testMethod() {
    }
    =======
    public void testMethod() { ...
    }
    >>>>>>> origin/<remotebranch>

où HEAD est modifié sur votre branche locale et origine /est modifié depuis la branche distante. Ici, conservez les éléments dont vous avez besoin et supprimez ceux dont vous n’avez pas besoin.Après cela, suivez les étapes normales. C'est

 
   git add TestClass.java
   git commit -m "commit message"
   git push
    
1
2017-08-07 15: 09: 13Z

Je suis le processus ci-dessous.

Processus de résolution des conflits de fusion:

  1. Commencez par extraire la dernière de la branche de destination à laquelle vous souhaitez fusionner git pull origin develop

  2. Au fur et à mesure que vous obtenez les dernières nouvelles de la destination, résolvez maintenant le conflit manuellement dans l'EDI en supprimant ces caractères supplémentaires.

  3. Utilisez un git add pour ajouter ces fichiers modifiés à la file d'attente git afin qu'il puisse être commit et push dans la même branche que celle sur laquelle vous travaillez.

  4. Lorsque git add est terminé, effectuez un git commit pour valider les modifications.

  5. Poussez maintenant les modifications dans votre branche active de git push origin HEAD

C’est cela et vous le verrez résolu dans votre demande d’aération si vous utilisez Bitbucket ou GitHub.

    
1
2017-11-23 09: 06: 54Z
source placée ici
D\'autres questions