Comment résoudre les conflits de fusion dans Git

Question

Existe-t-il un bon moyen d’expliquer comment résoudre les conflits de fusion dans Git?

Answer 1

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 beaucoup mieux que de faire le tout à la main, bien sûr.

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 installer l'un des outils suivants pour l'utiliser: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff , diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Vous trouverez ci-dessous un exemple de procédure permettant d’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

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

Step 2: Exécuter la commande suivante dans le terminal

git mergetool

Étape 3: vous verrez un affichage de vimdiff au format suivant 

  +----------------------+
  |       |      |       |
  |LOCAL  |BASE  |REMOTE |
  |       |      |       |
  +----------------------+
  |      MERGED          |
  |                      |
  +----------------------+

Ces 4 vues sont 

LOCAL - c'est un fichier de la branche courante 

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

REMOTE - fichier que vous fusionnez dans votre branche 

MERGED - 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 directement accéder à la vue MERGED en utilisant ctrl+w suivi de j.

Plus d'infos sur la navigation vimdiff ici et ici

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

Si vous souhaitez obtenir des modifications de REMOTE

:diffg RE  

Si vous souhaitez obtenir des 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 Supprime les fichiers supplémentaires (par exemple * .orig) créés par l’outil diff.

Answer 2

Voici un cas d'utilisation probable, du haut:

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

git fetch Origin
git pull Origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

Donc, vous vous mettez à jour et 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://[email protected]: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.

Alors vous décidez de regarder les changements:

git mergetool

Oh moi, oh, en amont, certaines choses ont changé, 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 on essaie une dernière fois

git pull Origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da!

Answer 3

Je trouve que les outils de fusion m'aident rarement à comprendre le conflit ou la ré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 astuces:

Astuce Un

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

git config merge.conflictstyle diff3

Cela 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 partie centrale est à quoi ressemblait l'ancêtre commun. Cela 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 n'est que de quelques lignes, cela rend généralement le conflit 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. à.)

Si le conflit dure plus longtemps, 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 causé 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 morceau de 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>

Cela montre 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 validations qui existaient déjà dans les deux branches avant la fusion.) Cela vous aide à ignorer les différences qui ne sont clairement pas un facteur dans votre conflit actuel.

Astuce Trois

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

Si vous avez des tests automatisés, lancez-les. Si vous avez un charpie , lancez-le. 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 de travail.)

Astuce Quatre

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

En planifiant à l'avance et en sachant ce sur quoi les autres travaillent, vous pouvez éviter les conflits de fusion et/ou vous aider à 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 une refactorisation différente qui affectera le même ensemble de fichiers, vous devriez vous parler à l'avance et avoir une meilleure idée des types de modifications que chacun de vous est. fabrication. 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. 

Dans le cas de 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 la forcez pas.

La fusion peut sembler fastidieuse, surtout lorsqu'il y a beaucoup de fichiers 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 les éléments généraux tels que la gestion d’une fusion complexe, ce qui donne l’impression qu’il faille passer plusieurs heures à disséquer chaque conflit.

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

Answer 4

1. Identifiez les fichiers en conflit (Git devrait vous le dire).

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 d'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 conflits, utilisez git rebase --continue ou une commande quelconque Git a dit de le faire lorsque vous avez terminé.

Answer 5

Consultez les réponses à la question Stack Overflow Abandon d'une fusion dans Git, en particulier 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

Answer 6

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

gitCLI

Voici les é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 méthodes 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 que vous avez 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 aux conflits pour une raison quelconque.}

     Connexes: Quelle est la signification précise de "our" et "leur" dans git?

   • Editez les fichiers en conflit manuellement et recherchez le bloc de code entre <<<<</>>>>>, puis choisissez la version ci-dessus ou ci-dessous =====. Voir: Comment les conflits sont présentés .

   • Les conflits de chemin et de nom de fichier peuvent être résolus avec git add/git rm.

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

   Si vous avez encore des fichiers sous 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 Push to remote comme d'habitude.

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

DiffMerge

J'ai utilisé avec succès DiffMerge , qui peut visuellement comparer et fusionner des fichiers sous Windows, MacOS et Linux/Unix.

Il peut afficher graphiquement les modifications entre 3 fichiers et permet la fusion automatique (lorsque cela est possible en toute sécurité) et un contrôle total sur la modification du fichier résultant.

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

Il suffit de le télécharger et de le lancer dans le dépôt comme:

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-Up/Down pour passer aux modifications précédentes/suivantes.
• ⌘-Alt-Left/Right accepter le changement de gauche ou de droite

Sinon, vous pouvez utiliser opendiff (une partie de Xcode Tools) qui vous permet de fusionner deux fichiers ou répertoires ensemble pour créer un troisième fichier ou répertoire.

Answer 7

Si vous faites souvent de petits commits, commencez par examiner les commentaires de validation avec git log --merge. Ensuite, git diff vous montrera les conflits.

Pour les conflits de 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 manquée le contexte.

Chaque fois que vous éditez un fichier pour résoudre un conflit, git add filename mettra à jour l'index et votre diff ne l'affichera plus. Lorsque tous les conflits sont résolus et que leurs fichiers ont été git add-, git commit complétera votre fusion.

Answer 8

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

De plus, 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 HEAD commettre pour inverser 2. et de nettoyer les modifications apportées à l'arbre de travail effectuées par 2. et 3 .; git merge --abort peut être utilisé pour cela.

• Résoudre les conflits. Git marquera les conflits dans l’arbre de travail. Éditez les fichiers en forme et git add les dans l'index. Utilisez git commit pour sceller l’affaire.

Vous pouvez résoudre le conflit avec plusieurs outils:

• Utilisez un outil de fusion. git mergetool pour lancer un outil de fusion graphique qui vous guidera tout au long de 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 affiche l'ancêtre commun, git show :2:filename indique la version HEAD et git show :3:filename indique 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 Pro Git book Basic Merge Conflicts .

Answer 9

Pour Emacs les 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 en:

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

Cela 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 la mine ou sa région dans le tampon de sortie, respectivement. Et/ou éditez directement le tampon de sortie.

Lorsque vous avez terminé: Appuyez sur 'q'. Emacs vous demande si vous souhaitez enregistrer ce tampon: oui . Après avoir terminé un tampon, marquez-le comme résolu en exécutant à partir du teriminal

git add FILENAME

Lorsque vous avez terminé avec tous les types de tampons

git commit

pour terminer la fusion.

Answer 10

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

Accepter pleinement ma ou leur version :

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 (à distance, la leur):

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

Si vous voulez faire pour tous les fichiers en conflit exécutez:

git merge --strategy-option ours

ou

git merge --strategy-option theirs

Examinez toutes les modifications et acceptez-les individuellement

1. git mergetool
2. Passez en revue 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"

La valeur par défaut mergetool fonctionne dans la ligne de commande . Comment utiliser un programme mergetool en ligne de commande doit être une question distincte.

Vous pouvez également installer outil visuel pour cela, par exemple. meld et courir

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é, exécutez à nouveau git mergetool -t meld jusqu'à ce que vous obteniez le message "Aucun fichier à fusionner", puis passez aux étapes 3 et 4.

Answer 11

Simplement, si vous savez bien que les changements dans l’un des référentiels n’ont pas d’importance et que vous souhaitez résoudre tous les changements en faveur de l’autre, utilisez:

git checkout . --ours

pour résoudre les changements 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 à un. Supposez que l'outil de fusion est p4merge ou écrivez le nom de n'importe quel nom déjà installé.

git mergetool -t p4merge

et après avoir fini un fichier, vous devrez sauvegarder et fermer, le prochain s'ouvrira.

Answer 12

Prime:

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 dans ma vie de git 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 git pull et merge manuel. Il synchronisera automatiquement les dernières modifications du serveur distant (avec une extraction + fusion) et placera votre dernière validation locale en haut du 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 des détails sur: http://gitolite.com/git-pull--rebase

Answer 13

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

Je pense que la vraie clé est de savoir comment les changements se produisent avec les référentiels locaux et distants. La clé de ceci 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 Origine. 

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

Au lieu de:

git add .
git commit -m"some msg"

Qui a deux inconvénients - 

a) Tous les fichiers nouveaux/modifiés sont ajoutés et peuvent inclure des modifications indésirables.
b) Vous ne pouvez pas commencer par consulter la liste des fichiers.

Alors à la place je fais:

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 à votre situation), j'essaie d'éviter:

git pull

ou

git pull Origin master.

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

Au lieu j'essaie de faire

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

Vous pouvez également trouver cela utile:

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

Answer 14

La réponse de CoolAJ86 résume à peu près tout. Si vous avez des modifications dans les deux branches du même morceau de 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 que le nouveau code soit, tout en supprimant les signes égaux et les chevrons. 

git commit -a -m "commit message"
git Push Origin master

Answer 15

Il y a 3 étapes:

1. Trouvez les fichiers qui provoquent des conflits par commande

   git status
   

2. Vérifiez les fichiers, dans lesquels vous trouveriez les conflits marqués comme

   <<<<<<<<head
   blablabla
   

3. Changez-le comme vous le voulez, puis validez avec des commandes

   git add solved_conflicts_files
   git commit -m 'merge msg'
   

Answer 16

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 est d’ouvrir deux lignes de commande et en une exécution.

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

et dans l'autre

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

Remplacer $MERGED_IN_BRANCH par la branche dans laquelle j'ai fusionné et [path] par le fichier en conflit. Cette commande enregistrera 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.

Answer 17

Utiliser patience

Je suis surpris que personne d'autre n'ait parlé de la résolution d'un conflit en utilisant 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 qu'il va essayer de faire correspondre des blocs plutôt que des lignes individuelles.

Si vous modifiez par exemple l'indentation de votre programme, 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

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 que vous voulez 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 avec 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 voulez seulement voir les modifications pour un fichier particulier:

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

Answer 18

À compter du 12 décembre 2016, vous pouvez fusionner des branches et résoudre des 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.

Cet article de blog explique en détail, mais les bases sont 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 fusions conflits.

 

Answer 19

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

• git checkout master (venez à la branche master)
• 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 auprès de votre maître.)

Maintenant, vous pouvez faire la même chose, conserver autant d’agences locales que vous le souhaitez et travailler simultanément avec une simple vérification de votre compte lorsque vous en avez besoin.

Answer 20

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

• Quand on lance "git fetch" puis "git merge"
• Quand on lance "git fetch" puis "git rebase"
• Lors de l'exécution de "git pull" (qui est en réalité égal à l'une des conditions mentionnées ci-dessus)
• Lorsque vous exécutez "git stash pop"
• Lorsque vous appliquez des correctifs git (commits exportés 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/

Si vous installez Git Extensions, l’assistant d’installation contient une option permettant d’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.)

Ensuite, 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:

 

Ensuite, une fois que vous avez terminé, enregistrez le fichier. Le fichier suivant est traité en conflit et vous recommencez jusqu'à ce que tous les conflits soient résolus.

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

$git mergetool
No files need merging

Answer 21

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

Étape 1: aller à la succursale

git checkout test

Étape 2: git pull --rebase Origin master

Étape 3: S'il y a des conflits, allez dans 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.

Answer 22

Cette réponse consiste à ajouter une alternative aux utilisateurs VIM comme I qui préfère tout faire dans l'éditeur.

---

TL; DR

 

---

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

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

• :diffget //2, récupère les modifications par rapport à la branche d'origine (HEAD): 
• :diffget //3, obtenez les modifications de la branche fusionnée: 

Une fois que vous avez fini de fusionner le fichier, tapez :Gwrite dans le tampon fusionné. Vimcasts a publié une grande vidéo expliquant en détail cette étape.

Answer 23

aller chercher 
git checkout votre branche
maître git rebase

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

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 ajouter
git rebase --continue
git commit --amend
git Push Origin HEAD: refs/drafts/master (Poussez comme un brouillon)

Maintenant tout va bien et vous trouverez votre engagement dans gerrit

J'espère que cela aidera tout le monde concernant cette question. 

Answer 24

Essayez d’éditer le code Visual Studio si vous n’êtes pas déjà . C’est après avoir essayé de fusionner (et atterri en conflits de fusion) que 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 m'a aidé et peut aussi fonctionner pour vous! 

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

Answer 25

Je suis le processus ci-dessous.

Le processus pour résoudre le conflit de fusion:

1. Tout d'abord, extraire le dernier 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 IDE en supprimant ces caractères supplémentaires.

3. Effectuez 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 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 par 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.

Answer 26

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

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

Il montrera tous les conflits comme celui-ci

A_MBPro: teste une fusion $ git origine/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

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

Ouvrez le fichier dans intelliJ, il aura des sections avec 

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

où HEAD correspond aux modifications de votre branche locale et Origin/aux modifications de la branche distante. Ici, conservez les éléments dont vous avez besoin et supprimez ceux dont vous n’avez pas besoin. C'est

   git add TestClass.Java
   git commit -m "commit message"
   git Push

Answer 27

Gitlense For VS Code

Vous pouvez essayer Gitlense pour VS Code, leurs principales caractéristiques sont:

3. Résoudre facilement les conflits.

J'aime déjà cette fonctionnalité:

 

2. Blame de la ligne en cours.

 

3. Gouttière

 

4. Blame de la barre d'état

 

Et il y a beaucoup de fonctionnalités que vous pouvez vérifier ici .

Answer 28

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. Faire 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. Un message indique maintenant que la fusion est en attente et que les fichiers en conflit sont répertoriés juste en dessous du message.

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

Answer 29

1. Créer une nouvelle branche de fonctionnalité à partir de la branche cible
2. Correction dans les modifications de la branche de fonctionnalité en conflit
3. Résoudre les conflits dans l'outil de différenciation lors de l'application du correctif
4. Valider/réviser la demande de tirage propre
5. Supprimez la branche en conflit. 

Cela a toujours été plus rapide et plus facile pour moi que d'utiliser Git. Cela est particulièrement utile si les modifications gâchent une demande d'extraction et que votre IDE ne gère pas très bien la fusion de Git.

Answer 30

git checkout branch1

git fetch Origin

git rebase -p Origin/mainbranch

S'il y a des conflits de fusion, corrigez-les. Ensuite, continuez le processus de rebase en exécutant: git rebase –-continue

après la réparation, vous pouvez valider et pousser votre succursale locale vers une succursale distante

git Push Origin branch1

Answer 31

Un moyen plus sûr de résoudre les conflits est d’utiliser git-mediate (les solutions communes suggérées ici sont très mal à l’aise).

Voir cet article pour une introduction rapide sur son utilisation.

Answer 32

Beyond Compare est installé. Ainsi, lorsque vous utilisez git mergetool, il se déclenche en Colombie-Britannique, qui dispose d’un moyen très agréable d’utiliser une fusion.