Cherry-pick : ce que c’est, comment l’exécuter et commandes Git
Cherry-pick est une commande Git qui applique les modifications d’un commit spécifié à la branche actuelle sans transférer tout l’historique de la branche source. Contrairement à merge ou rebase, cherry-pick travaille avec chaque commit individuellement : le développeur sélectionne un commit spécifique par son hash et ne transfère que ses modifications. Selon la documentation Git (2026), cherry-pick est particulièrement utile pour le transfert ciblé de corrections entre branches de release lorsqu’un merge complet est excessif ou risqué. La commande crée un nouveau commit avec un nouveau hash, mais conserve le message original et l’auteur.
Points clés
- Cherry-pick — transfert d’un commit individuel d’une branche à une autre par son hash.
- Nouveau hash — chaque cherry-pick crée un nouveau commit avec les modifications copiées de l’original.
- Plusieurs commits à la fois — git cherry-pick A B C transfère les commits spécifiés séquentiellement.
- Branches de release — le scénario principal : déplacer une correction de develop vers release sans code inutile.
- Conflits possibles — lors de l’application d’un commit, Git peut demander la résolution de conflits.
Qu’est-ce que cherry-pick dans Git
Cherry-pick est la commande git cherry-pick qui prend les modifications d’un commit existant et les applique comme un nouveau commit dans la branche actuelle. Le commit original reste en place dans sa propre branche, tandis qu’une copie des modifications est créée dans la branche de destination. La commande est utile lorsque vous devez transférer une correction spécifique sans déplacer une branche entière.
Syntaxe : git cherry-pick <commit-hash>. Git analyse la différence (diff) du commit spécifié par rapport à son parent et applique cette différence à la branche actuelle. Si plusieurs fichiers sont modifiés, ils sont tous transférés ensemble. La commande accepte également des plages : git cherry-pick A..B — tous les commits de A à B, excluant A.
Les drapeaux étendent ses capacités : -n (--no-commit) applique les modifications au répertoire de travail et à l’index sans créer de commit — utile lorsque vous devez combiner les modifications de plusieurs commits en un seul. Le drapeau -x ajoute une ligne (cherry picked from commit ...) au message du commit, facilitant le suivi de l’origine des modifications dans l’historique.
bash
# Cherry-pick d’un seul commit par hash
git cherry-pick a1b2c3d
# Cherry-pick de plusieurs commits (séquentiellement)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l
# Cherry-pick sans auto-commit
git cherry-pick -n a1b2c3d
# Le drapeau -x ajoute une référence au commit original
git cherry-pick -x a1b2c3dQuand utiliser cherry-pick
Le scénario principal est le transfert de corrections entre branches de release. Imaginez : un bug critique a été trouvé et corrigé dans develop. La branche de release release/v2.1 est déjà séparée et contient également ce bug. Fusionner tout develop dans release apporterait beaucoup de code non terminé, tandis qu’appliquer cherry-pick au seul commit de correction est une solution sûre et précise.
Le deuxième scénario est l’annulation de modifications avec restauration ultérieure. Si un commit a été annulé via git revert et qu’il s’avère ensuite que l’annulation était une erreur — appliquer cherry-pick au commit annulé restaure les modifications. C’est plus correct que d’annuler un revert car cela ne crée pas de conflits répétés.
Le troisième scénario est la combinaison de commits de différentes branches de fonctionnalités dans une branche de test pour les tests d’intégration. Au lieu de fusionner plusieurs branches inachevées (avec du code incomplet), vous pouvez sélectionner uniquement les commits prêts de chacune et tester leur fonctionnement ensemble.
- Corrections de bugs — transférer une correction de develop vers release sans code non terminé.
- Hotfix — appliquer une correction d’une branche hotfix vers main et develop simultanément.
- Annulation d’un revert erroné — appliquer cherry-pick au commit annulé pour restaurer les modifications.
- Tests — collecter des commits sélectionnés de différentes branches pour des tests d’intégration.
Cherry-pick vs rebase et merge
Cherry-pick diffère de rebase et merge car il travaille au niveau des commits individuels plutôt que des branches entières. Alors que rebase transfère tous les commits d’une branche et merge combine deux branches, cherry-pick ne sélectionne que ceux nécessaires. Cela en fait un outil plus précis, mais aussi plus manuel.
Une autre différence est l’auteur. Lors du cherry-pick, Git conserve par défaut l’auteur du commit original, mais le committer devient l’utilisateur actuel. Le message du commit peut retracer l’origine via le drapeau -x. Lors du rebase, l’auteur et le committer deviennent tous deux l’utilisateur actuel avec un nouveau hash.
Performance : appliquer cherry-pick à un seul commit est plus rapide que de fusionner deux branches avec de nombreux commits. Mais si vous devez transférer des dizaines de commits, il est préférable de créer une branche temporaire et d’effectuer un rebase — ce sera plus efficace et ne nécessitera pas de spécifier des dizaines de hashs.
| Opération | Portée | Effets secondaires |
|---|---|---|
| Cherry-pick | Commits individuels | Nouveau hash, duplication de code |
| Rebase | Tous les commits d’une branche | Réécriture de l’historique, nouveaux hashs |
| Merge | Fusion complète de branches | Commit de merge, conservation de l’historique |
Transférer plusieurs commits
Plusieurs commits peuvent être transférés avec une seule commande en listant leurs hashs séparés par des espaces : git cherry-pick A B C. Git applique les commits séquentiellement dans l’ordre spécifié. Si un commit provoque un conflit, cherry-pick est mis en pause et le développeur doit résoudre le conflit, puis continuer avec git cherry-pick --continue.
Plage de commits : git cherry-pick A..B (tous les commits après A jusqu’à B, excluant A) et git cherry-pick A^..B (tous les commits de A inclus jusqu’à B). Les plages sont pratiques lorsque vous devez transférer tous les commits d’une branche sans la relation parent — par exemple, lors du déplacement d’une fonctionnalité complète d’une ancienne branche vers une nouvelle.
Le drapeau --strategy détermine comment Git applique les modifications. Par défaut, la stratégie recursive est utilisée, mais vous pouvez spécifier ours ou theirs pour sélectionner automatiquement un côté du conflit. Le drapeau --mainline est utilisé lors du cherry-pick d’un commit de merge — il spécifie le numéro du parent (1 ou 2) par rapport auquel le diff est calculé.
bash
# Plage de commits cherry-pick
git cherry-pick develop~5..develop~2
# Cherry-pick de commit de merge (spécifier le parent)
git cherry-pick -m 1 m9n0o1p
# Utiliser la stratégie theirs
git cherry-pick --strategy=recursive \
--strategy-option=theirs a1b2c3d
# Continuer après la résolution de conflit
git cherry-pick --continueConflits lors de cherry-pick
Les conflits lors de cherry-pick surviennent lorsque les modifications du commit transféré affectent les mêmes lignes qui ont été modifiées dans la branche de destination. Git met en pause l’exécution, marque les fichiers en conflit et attend la résolution. Dans le statut, ces fichiers apparaissent comme both modified.
Étapes pour résoudre un conflit : ouvrez le fichier en conflit, trouvez les marqueurs de conflit (<<<<<<<, =======, >>>>>>>), modifiez le contenu, supprimez les marqueurs, exécutez git add pour les fichiers résolus et exécutez git cherry-pick --continue. Si le conflit ne peut pas être résolu — git cherry-pick --abort annule tout le cherry-pick, ramenant la branche à son état d’origine.
Un problème courant : le commit contient déjà des modifications équivalentes à celles existantes. Dans ce cas, Git signale « nothing to commit » ou « empty commit » lors de la tentative de cherry-pick. Les drapeaux --keep-redundant-commits et --empty=keep forcent Git à créer un commit vide pour préserver la séquence, tandis que --skip permet de sauter un tel commit.
bash
# Conflit lors du cherry-pick — arrêt
git cherry-pick a1b2c3d
# error : impossible d’appliquer a1b2c3d... message du commit
# Résoudre le conflit → ajouter à l’index
git add src/conflicted_file.swift
git cherry-pick --continue
# Sauter le commit vide (déjà appliqué)
git cherry-pick --skip
# Annulation complète
git cherry-pick --abortBonnes pratiques de cherry-pick
Première règle : vérifiez toujours que le commit transféré est autonome. Si le commit A dépend de modifications du commit B qui n’est pas transféré, appliquer cherry-pick à A peut casser la compilation. Avant le cherry-pick, il est utile de vérifier quels fichiers le commit a modifiés via git show --stat <hash>.
Deuxième règle : documentez les opérations de cherry-pick. Utilisez le drapeau -x pour que le message du commit conserve une référence au commit original. Cela aidera lors de l’analyse ultérieure de l’historique à comprendre d’où vient la modification. Sans -x, un cherry-pick ressemble à un commit normal et son origine ne peut être déterminée que via git log --graph.
Troisième règle : évitez le cherry-pick entre des branches qui ont trop divergé. Si beaucoup de temps s’est écoulé depuis la création du commit et que la base de code a considérablement changé, les conflits seront nombreux et complexes. Dans ce cas, il est préférable de réimplémenter la correction dans la branche de destination — cela prendra moins de temps que de résoudre des dizaines de conflits.
- Cherry-pick uniquement les commits autonomes sans dépendances externes.
- Le drapeau -x est obligatoire pour documenter l’origine du commit dans le message.
- Évitez d’appliquer cherry-pick à des commits anciens avec une grande divergence de la base de code.
- CI/CD vérifiez la compilation après cherry-pick : un conflit peut ne pas s’être produit, mais le code peut ne pas compiler.
- Commentaire dans la PR lors de la création d’une pull request, indiquez quels commits ont été transférés via cherry-pick.
Questions fréquentes
Que signifie appliquer un cherry-pick à un commit ?
Appliquer un cherry-pick signifie appliquer les modifications d’un commit spécifié à la branche actuelle via git cherry-pick. La commande crée un nouveau commit avec les mêmes modifications mais un nouveau hash. Le commit original reste inchangé dans sa branche. C’est une alternative à la fusion d’une branche entière lorsqu’un seul commit spécifique est nécessaire.
Quand utiliser cherry-pick au lieu de merge ?
Cherry-pick est choisi lorsque vous devez transférer un ou plusieurs commits spécifiques sans déplacer toute la branche. Merge est utilisé pour la fusion complète de branches. Un scénario typique de cherry-pick est le transfert d’une correction de bug d’une branche de développement vers une branche de release où les autres modifications ne sont pas encore prêtes.
Peut-on annuler un cherry-pick ?
Avant la fin — git cherry-pick --abort annule complètement l’opération. Après une fin réussie — git revert <hash> crée un commit qui annule les modifications du cherry-pick. La différence avec --abort : revert ne supprime pas le commit de l’historique, mais crée un nouveau commit d’annulation.
Que faire si cherry-pick crée un commit vide ?
Un commit vide se produit lorsque les modifications existent déjà dans la branche de destination. Utilisez git cherry-pick --skip pour sauter un tel commit, ou git cherry-pick --keep-redundant-commits pour créer un commit vide et préserver la séquence des hashs.
En quoi cherry-pick diffère-t-il de rebase ?
Cherry-pick transfère les commits sélectionnés (un par un ou sous forme de liste) vers la branche actuelle. Rebase déplace tous les commits d’une branche vers une nouvelle base. Cherry-pick ne modifie pas la branche source, rebase réécrit l’historique. Cherry-pick est précis mais manuel ; rebase est automatique mais dangereux pour les branches publiques.
Résumé
- Cherry-pick — une commande pour transférer des commits individuels entre branches en préservant les modifications et en créant un nouveau hash.
- Scénario principal — transférer des corrections entre branches de release sans déplacer tout l’historique ou le code non terminé.
- Plusieurs commits sont transférés avec une seule commande en listant les hashs ou en utilisant une plage A..B.
- Conflits sont résolus de la même manière qu’avec merge : modifier les fichiers, git add, git cherry-pick --continue.
- Le drapeau -x ajoute une référence au commit original dans le message pour la transparence de l’historique.
- Annulation se fait via --abort avant la fin ou git revert après.
- Risques : appliquer cherry-pick à des commits dépendants et à des modifications très anciennes peut provoquer plusieurs conflits.
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi