Lorsque Git ne peut pas combiner deux branches automatiquement, il s'interrompt et vous laisse le soin de concilier les modifications concurrentes. Sur Mac, utilisez git status pour identifier les fichiers concernés, comparez les deux versions, modifiez chaque conflit afin d'obtenir un résultat combiné réfléchi, puis indexez et finalisez la fusion. L'essentiel est de préserver l'intention des deux modifications, sans accepter aveuglément un côté ni supposer que la conservation des deux blocs produira un code fonctionnel.

Confirmer l'opération et protéger les modifications non enregistrées

Ouvrez Terminal ou le terminal intégré de votre éditeur, placez-vous dans le dépôt et vérifiez son état :

cd "/path/to/repository"
git status

Remplacez l'exemple par le chemin réel du dossier. L'état renvoyé par Git vous indique quels fichiers ne sont pas fusionnés et si l'opération en cours est une fusion (merge), un rebasage (rebase) ou une autre action. Cet article traite d'une fusion. Lors d'une fusion classique, Git conserve la branche courante en place pendant qu'il attend que vous résolviez les conflits ; les chemins fusionnés sans encombre sont déjà mis à jour, tandis que les chemins en conflit doivent être examinés. Documentation Git pour git merge

Si vous avez des modifications non commitées antérieures à la fusion, veillez à ne pas les écraser lors de vos éditions. La documentation de Git présente git merge --abort comme un moyen d'interrompre une fusion, tout en signalant qu'elle ne permet pas toujours de reconstruire les modifications locales préexistantes non validées. En cas de doute, enregistrez une copie distincte de vos modifications locales importantes avant de poursuivre. N'annulez que si vous souhaitez réellement interrompre la fusion, et inspectez l'état obtenu par la suite. Instructions de Git sur les conflits de fusion

Considérer chaque conflit comme deux propositions

Ouvrez chaque fichier listé dans un éditeur de texte. Un conflit textuel se présente généralement ainsi :

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> branch-name

Le texte situé au-dessus de ======= correspond généralement à la version de la branche courante ; le texte en dessous correspond en règle générale à la branche en cours de fusion. Les libellés peuvent varier. Git enregistre l'ancêtre commun et les versions des deux branches dans l'index, et le fichier de travail affiche un résultat jalonné de marqueurs de conflit que vous devez modifier. Documentation Git sur la fusion

Abordez ces deux sections comme des indications des modifications souhaitées, et non comme des options à accepter intégralement en l'état. Demandez-vous ce que chaque modification cherchait à accomplir. Un côté peut ajouter une condition de validation tandis que l'autre modifie le nom d'un champ ; préserver les deux peut impliquer de les combiner en une seule condition mise à jour. Dans le cas d'un conflit au niveau d'un fichier (par exemple, si un côté supprime un fichier alors que l'autre le modifie), déterminez si le fichier doit être conservé et, le cas échéant, intégrez les modifications nécessaires. Si l'intention n'apparaît pas clairement à la lecture des lignes, examinez le code environnant ou interrogez l'auteur de la modification avant de trancher.

Supprimez tous les marqueurs de conflit et rédigez une version finale cohérente. Ne laissez pas simplement les deux blocs l'un à la suite de l'autre, à moins que ce ne soit précisément ce que le programme ou le document doit contenir. Conserver les deux peut dupliquer des déclarations, écraser des comportements ou introduire une syntaxe invalide. Inversement, ne choisir qu'un seul bloc peut éliminer le travail utile de l'autre branche. La résolution appropriée dépend du reste du fichier et de la finalité de chaque modification.

Vérifier et indexer les fichiers résolus

Enregistrez le fichier modifié, puis inspectez les changements. Pour un fichier en conflit, git diff affiche le travail de résolution de conflit toujours présent dans votre arbre de travail. Examinez l'ensemble du contexte environnant, et pas seulement les lignes marquées. Recherchez les marqueurs résiduels à l'aide de la fonction de recherche de votre éditeur, ou exécutez cette commande dans le dépôt :

git grep -n -E '^(<<<<<<<|=======|>>>>>>>)'

Si la commande trouve des correspondances, examinez-les : de la documentation légitime ou des jeux de données de test peuvent contenir ces chaînes, ne supprimez donc pas les résultats sans discernement. Dès que le contenu d'un fichier est correct, indexez-le en passant son chemin entre guillemets à git add, par exemple git add "Sources/Example.swift". L'indexation indique à Git que le conflit du fichier a été résolu ; elle ne garantit pas que le résultat est correct. Les instructions de Git préconisent de corriger chaque conflit, d'ajouter les chemins résolus, puis de commiter ou de poursuivre la fusion. Documentation de Git sur la fusion

Pour une approche visuelle sur Mac, Visual Studio Code regroupe les fichiers en conflit sous Modifications de fusion (Merge Changes) dans la vue Contrôle de code source. Ouvrez un fichier et utilisez les actions de conflit intégrées au texte ou cliquez sur Ouvrir dans l'éditeur de fusion pour inspecter la version courante, la version entrante et le résultat. L'action Accepter les deux modifications de l'éditeur conserve les deux sections à la suite ; relisez le fichier obtenu et combinez ou ajustez le contenu si nécessaire. Enregistrez le résultat et indexez le fichier dans Contrôle de code source. Ces commandes sont propres à VS Code ; d'autres éditeurs peuvent employer des intitulés ou des fonctionnalités différents. Guide de VS Code sur les conflits de fusion

Finaliser la fusion et vérifier le résultat

Une fois chaque fichier en conflit résolu et indexé, vérifiez à nouveau l'état :

git status
git diff --cached

Examinez le diff indexé pour vous assurer que les deux contributions prévues apparaissent sous une forme finale cohérente et qu'aucune modification superflue n'a été incluse. Exécutez les tests ou vérifications pertinents du projet si disponibles ; Git ne peut pas déterminer si la logique combinée fonctionne comme prévu.

Pour une fusion en ligne de commande, terminez l'opération avec git merge --continue (ou validez la fusion par un commit lorsque Git vous y invite). La commande --continue de Git s'assure qu'une fusion est bien en cours avant de créer le commit. Exécutez ensuite de nouveau git status pour confirmer que l'opération de fusion est terminée. Si Git signale d'autres conflits, résolvez et indexez également ces fichiers. Instructions de fusion de Git

Un conflit est résolu en toute sécurité lorsque le fichier final intègre de façon délibérée le travail prévu par les deux branches, que le diff indexé correspond à ce résultat et que la fusion est achevée. Si vous ne parvenez pas à déterminer ce qu'un côté cherchait à accomplir, marquez une pause et renseignez-vous sur ce contexte avant de supprimer ou de réécrire le code en question.

Sources