Git Cherry-pick : copiez un commit dans une autre branche et corrigez les conflits

Git Cherry-pick applique la modification introduite par un commit à votre branche actuelle, en enregistrant généralement un nouveau commit. Basculez vers la branche qui doit recevoir le correctif, inspectez le commit source, puis exécutez git cherry-pick <commit>. La branche source reste en place. Si le correctif est en conflit, résolvez les fichiers et continuez, ou abandonnez l'opération.

Imaginez un bug de paiement corrigé sur feature/checkout, alors qu'une branche de version n'a besoin que de ce correctif. La fusion de l’ensemble de la fonctionnalité pourrait entraîner un travail inachevé. Ce guide montre comment copier uniquement le correctif avec Git et avec GitTree, le client que nous construisons pour macOS, Windows et Linux. La valeur supplémentaire de l'itinéraire visuel est de vérifier la branche de destination et la différence source avant d'appliquer le changement.

Cherry-pick vs merge vs rebase : choisissez l'opération

Cherry-pick est utile pour un backport ou un petit correctif commis sur la mauvaise branche. C'est un mauvais substitut à la fusion répétée de deux branches qui devraient partager tout leur travail : les modifications copiées peuvent devenir difficiles à suivre. Pour un workflow de branche entière, consultez rebase interactif et le guide du graphique de validation.

Comment sélectionner un commit sur une autre branche

Commencez avec un arbre de travail propre. Valider ou cacher les modifications inachevées ; le guide de cachette couvre ce flux de travail de pause et de reprise. Récupérez si le correctif est distant, puis inspectez l'historique source. Les noms de branche et le hachage ci-dessous sont des exemples : remplacez-les par une branche de destination existante, votre branche source et le hachage du correctif réel.

git status
git fetch origin
git log --oneline origin/feature/checkout
git show abc1234
git switch release/2.x
git status
git cherry-pick -x abc1234
git show --stat HEAD
git status

-x ajoute la référence de validation source au message pour une sélection claire, ce qui permet de tracer les rétroportages publics. Récupérer les mises à jour des références de suivi à distance ; il ne met pas automatiquement à jour votre branche de version extraite. Confirmez que la destination correspond à la révision attendue par votre équipe. Vérifiez le nouveau commit et exécutez les tests de la branche release avant de le pousser.

La validation sélectionnée a normalement un hachage différent car ses métadonnées parent et les autres métadonnées de validation diffèrent. Son original reste sur la branche source. Copier un correctif ne le supprime pas de la mauvaise branche ; décider comment nettoyer cette branche est une décision historique distincte, surtout si d'autres personnes l'utilisent déjà.

Téléchargez GitTree pour suivre ce flux de travail avec un graphique visuel et un éditeur de conflits. Cherry-pick est inclus dans le plan gratuit, y compris les référentiels privés. Connectez-vous à l'application officielle actuelle, ouvrez votre référentiel existant et utilisez le même historique Git que vous avez déjà.

Sélectionnez plusieurs commits et plages

git cherry-pick abc1234 def5678
# A linear range, including the first commit:
git cherry-pick "abc1234^..def5678"

Ce sont des exemples alternatifs. Une liste explicite sélectionne les commits dans l'ordre fourni ; donner la priorité aux modifications préalables. Une plage suit les règles des ensembles de révisions plutôt que de sélectionner les lignes que vous voyez dans un graphique. A..B exclut A ; A^..B inclut A pour une séquence linéaire simple lorsque A a un parent. Pour un backport débutant, préférez une liste explicite et révisée sur une plage qui traverse les fusions.

Résolvez les conflits de sélection et continuez

Lorsque Git ne peut pas appliquer le correctif, il se met en pause. Exécutez git status pour identifier l'opération et les chemins en conflit, puis modifiez le résultat souhaité. Utilisez le guide de résolution des conflits pour des exemples de marqueurs et l'éditeur à trois voies GitTree. Une résolution syntaxiquement propre nécessite encore des tests : la destination peut utiliser différentes API.

git status
git diff --name-only --diff-filter=U
# Resolve the file, then check and stage it:
git diff --check
git add -- src/payment.ts
git diff --cached
git cherry-pick --continue

Une séquence peut s'arrêter plusieurs fois, une fois pour chaque validation problématique. Si Git indique que le choix est vide, vérifiez si la modification est déjà présente ou si votre résolution l'a supprimée. Utilisez git cherry-pick --skip uniquement lorsque vous souhaitez délibérément omettre ce commit ; il ne s'agit pas d'une solution générale à un conflit.

Git choisir entre abandonner, quitter ou ignorer

Fusionner les commits, les dépendances manquantes et annuler une sélection

Une validation de fusion a besoin d’un parent principal car elle représente des modifications relatives à plusieurs parents. Inspectez-le avec git show --no-patch --pretty=raw <merge> avant d'envisager git cherry-pick -m 1 <merge>. Le parent 1 n’a pas tout à fait raison. GitTree vous demande de sélectionner le parent ; choisissez en fonction de l'histoire avec laquelle vous souhaitez comparer, et non par habitude. Il est souvent plus facile de raisonner sur le choix du commit de correctif ordinaire d'origine.

Si le correctif copié n'est pas construit correctement, inspectez ses prérequis : un assistant, une modification de schéma ou une configuration peut résider dans une validation antérieure. Une opération Git réussie prouve uniquement que le correctif a été appliqué. Testez la branche réceptrice. Pour annuler une sélection terminée sur l'historique partagé, annulez le nouveau commit créé sur la branche de destination, et non le hachage source d'origine. Pour les travaux non publiés, examinez les choix de réinitialisation et de récupération dans annulation des erreurs Git avant de déplacer l'historique de la branche.