Sur un Mac, résolvez un conflit de cherry-pick en modifiant chaque fichier en conflit dans Terminal ou un éditeur de code, en indexant les fichiers terminés avec git add, et en exécutant git cherry-pick --continue. Git s'interrompt car il n'a pas pu appliquer un commit proprement ; votre branche actuelle n'a pas encore reçu ce commit. Examinez les deux côtés de chaque conflit avant de continuer, et utilisez git cherry-pick --abort si vous décidez de ne pas poursuivre. La documentation de cherry-pick de Git décrit cet état de pause et ses options de reprise.

1. Ouvrir Terminal dans le dossier du projet

Ouvrez Terminal depuis Spotlight ou depuis le dossier Applications > Utilitaires du Finder. Dans Terminal, déplacez-vous vers le dossier du dépôt avec cd et son chemin. Pour un chemin de dossier contenant des espaces, mettez-le entre guillemets, par exemple cd "/Users/sam/Work/My Project". Vous pouvez également taper cd suivi d'un espace, faire glisser le dossier du projet depuis le Finder dans la fenêtre de Terminal, puis appuyer sur Retour. Apple décrit Terminal comme l'interface de ligne de commande de macOS ; son invite se termine souvent par % lorsque vous utilisez le shell par défaut zsh. Le guide de Terminal d'Apple explique comment l'ouvrir et reconnaître l'invite.

Confirmez que vous êtes dans le dépôt et vérifiez ce que rapporte Git avant de modifier des fichiers :

git status

Si la sortie indique qu'un cherry-pick est en cours et cite des chemins en conflit, continuez ci-dessous. Si vous n'êtes pas certain du dépôt ou du commit concerné, arrêtez-vous et confirmez ce contexte avant de résoudre quoi que ce soit. Ne démarrez pas un second cherry-pick pendant que le premier est en pause.

2. Inspecter le conflit et décider de ce que le fichier doit contenir

Ouvrez chaque fichier texte en conflit dans votre éditeur. Git insère des marqueurs autour des sections qu'il n'a pas pu réconcilier. Une section typique ressemble à ceci :

<<<<<<< HEAD
content on the current branch
=======
content from the commit being cherry-picked
>>>>>>> commit subject or identifier

HEAD correspond à la version de la branche actuelle ; l'autre section provient du commit en cours d'application. Ces étiquettes décrivent les deux côtés de cette opération, mais elles ne vous indiquent pas quelle version est la bonne. Servez-vous du code environnant, du changement prévu et de l'objectif du commit pour décider de conserver un côté ou de les combiner. La documentation de Git explique que les fichiers en conflit contiennent des marqueurs et que les chemins appliqués proprement peuvent déjà être mis à jour. Git cherry-pick

Modifiez le fichier pour qu'il contienne le résultat escompté, en supprimant toutes les lignes de marqueurs de conflit. Vérifiez chaque conflit dans ce fichier, enregistrez-le, et répétez l'opération pour chaque chemin listé par git status. Pour un fichier binaire ou un conflit dont le résultat souhaité n'est pas clair, ne devinez pas : consultez l'auteur de la modification ou les directives du projet avant de choisir une version. Évitez de remplacer un fichier entier par l'un des deux côtés simplement pour faire disparaître le conflit ; cela peut annuler des modifications valides.

3. Indexer les résolutions et les examiner

Après avoir résolu un fichier, indiquez à Git que son conflit est résolu en l'indexant. Utilisez le chemin exact indiqué par git status ; mettez entre guillemets les chemins contenant des espaces :

git add "Sources/Example File.swift"

Répétez pour chaque chemin résolu. git add indexe le contenu actuel du fichier, vérifiez donc ce que vous indexez s'il contient des modifications sans rapport. Le manuel de git-add de Git documente qu'il ajoute le contenu des fichiers à l'index, la zone de staging utilisée pour le prochain commit. Git add

Vérifiez s'il reste des conflits et inspectez la résolution indexée :

git status
git diff --cached

git status ne devrait plus lister de chemins non résolus. Lisez le diff indexé et confirmez à la fois que la modification souhaitée est présente et que les marqueurs de conflit ou les modifications accidentelles sont absents. git diff --cached affiche les modifications indexées ; Git diff documente cette option d'examen. Si vous repérez une erreur, modifiez le fichier, indexez-le à nouveau et examinez le diff encore une fois.

4. Continuer le cherry-pick

Lorsque tous les conflits sont résolus et indexés, exécutez :

git cherry-pick --continue

Git reprend l'opération suspendue et, en cas de succès, enregistre la modification cherry-pickée sous la forme d'un nouveau commit. Si Git ouvre un éditeur pour le message de validation, enregistrez et fermez-le en utilisant les commandes habituelles de cet éditeur. Vérifiez ensuite git status et examinez le dernier commit si nécessaire :

git status
git log -1 --oneline

Pour une séquence de commits cherry-pickés, --continue poursuit l'opération ; un commit ultérieur peut également s'interrompre en raison de conflits. Résolvez et indexez les conflits de ce commit de la même manière. Git documente --continue pour reprendre un cherry-pick interrompu et --skip pour ignorer le commit en cours. N'utilisez --skip que lorsque vous souhaitez intentionnellement omettre la modification de ce commit, et non comme raccourci pour des fichiers non résolus. Options de Git cherry-pick

Si vous préférez arrêter à la place

Si vous décidez que le cherry-pick ne doit pas se poursuivre, exécutez git cherry-pick --abort. Git documente cela comme une annulation de l'opération et un retour à l'état précédant le début de la séquence. Si vous aviez du travail en local avant de commencer, vérifiez-le ensuite avec git status ; n'utilisez pas de commandes de réinitialisation destructrices pour compenser une méconnaissance de l'état actuel. Git cherry-pick

Une règle d'arrêt utile est simple : ne continuez qu'après avoir compris le contenu souhaité de chaque fichier en conflit et examiné le résultat indexé. Si l'intention du code n'est pas claire, maintenez l'état de pause et demandez des conseils spécifiques au projet avant de créer le commit.

Sources