Cherry-pick — ce que c'est, mécanisme et application dans Git

Qu'est-ce que Cherry-pick ?

Cherry-pick est une commande Git qui copie les modifications d'un commit spécifié et les applique comme un nouveau commit dans la branche courante. Le nom vient de la métaphore du « cueillage de cerises » : le développeur sélectionne uniquement les commits dont il a besoin, ignorant le reste.

Contrairement à Merge, cherry-pick ne crée pas de commit de fusion et ne nécessite pas de fusion complète des branches. Contrairement à Rebase, cherry-pick ne transfère pas une séquence de commits — seulement ceux spécifiés. Cela fait de cherry-pick un outil idéal pour le transfert ciblé de correctifs.

Selon Atlassian, 2025, cherry-pick est utilisé par 47 % des équipes travaillant avec plusieurs branches de release simultanément. Cherry-pick est particulièrement demandé dans le développement mobile, où plusieurs versions d'une application (releases LTS) sont maintenues simultanément et nécessitent le transfert de correctifs entre elles.

Mécanisme de transfert

Lors de l'exécution de cherry-pick, Git calcule le diff entre le commit spécifié et son parent, puis applique ce diff à la branche courante. Si les modifications sont appliquées sans conflit — Git crée un nouveau commit avec le même message mais un nouveau SHA. En cas de conflit — cherry-pick s'arrête pour résolution manuelle.

Comment fonctionne Cherry-pick

La syntaxe de cherry-pick est simple : spécifiez le hash du commit à transférer. Git copie les modifications dans la branche courante comme un nouveau commit. Le transfert de plusieurs commits à la fois et de plages entières est pris en charge.

# Transférer un commit individuel vers la branche courante
git cherry-pick a1b2c3d4

# Transférer plusieurs commits
git cherry-pick a1b2c3d4 e5f6g7h8

# Transférer une plage de commits (de a1b2 à f9e8, sans inclure a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Après exécution de cherry-pick, la branche courante reçoit un nouveau commit avec les modifications de la source. Le message du commit est copié de la source par défaut, mais peut être modifié avec le flag -n (ne pas créer de commit) ou --edit (modifier le message).

Exemple de transfert d'un correctif

Considérons un scénario typique : un bug critique est trouvé et corrigé dans develop, qui existe également dans la branche de release release/v2.0. Seul ce correctif doit être transféré, sans fusionner tout develop dans la branche de release.

# Trouver le hash du commit avec le correctif dans develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Basculer vers la branche de release
git checkout release/v2.0

# Appliquer le correctif
git cherry-pick a1b2c3d4

# En cas de conflit — résoudre et continuer
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Le flag -x ajoute une référence au SHA original dans le message du commit : « (cherry picked from commit a1b2c3d4) ». Cela facilite le suivi de l'origine du commit transféré. Il est recommandé d'utiliser -x dans tous les scénarios sauf les brouillons temporaires.

Gestion des conflits

En cas de conflit, cherry-pick se comporte comme merge : Git s'arrête et marque les fichiers en conflit. Le développeur résout le conflit, exécute git add puis git cherry-pick --continue. Pour annuler — git cherry-pick --abort. Le flag --strategy permet de spécifier une stratégie de fusion (par exemple, recursive avec options).

# Résolution d'un conflit lors de cherry-pick
# Git montre les fichiers en conflit
git status

# Résoudre manuellement, puis :
git add fichier_autorisé.kt
git cherry-pick --continue

# Ou annuler cherry-pick :
git cherry-pick --abort

Quand utiliser Cherry-pick

Cherry-pick est optimal dans les scénarios où un transfert ciblé de modifications est nécessaire sans fusionner des branches entières. Examinons cinq cas principaux où cherry-pick devient le meilleur choix.

• Transfert de hotfix — un correctif est trouvé dans develop, mais doit être appliqué à la branche de release (release/v2.0). Cherry-pick transfère uniquement le commit du correctif sans affecter les fonctionnalités inachevées de develop
• Backport vers des versions anciennes — un correctif pour la version actuelle doit être transféré vers une release LTS. Au lieu de fusionner toute la base de code actuelle, cherry-pick sélectionne uniquement les commits nécessaires
• Annulation d'un commit dans la mauvaise branche — si un commit a été fait dans la mauvaise branche, cherry-pick le transfère dans la bonne, et le commit original est annulé
• Transfert de documentation — les modifications dans README ou les fichiers de configuration qui doivent être dans toutes les branches sont pratiques à transférer via cherry-pick
• Application sélective — à partir d'une branche prototype, un seul commit réussi doit être repris sans transférer tout le prototype dans le développement principal

Pour le développement mobile, cherry-pick est crucial lors de la prise en charge de plusieurs versions d'une application. Par exemple, si un bug est trouvé dans la version 3.2 déjà publiée sur Google Play, et que develop contient le code pour la version 4.0 — cherry-pick permet de transférer le correctif vers la branche v3.x sans fusionner toutes les modifications cassantes. Ceci est particulièrement pertinent pour les projets où deux versions majeures ou plus avec des API et dépendances différentes sont maintenues simultanément.

Exemple pratique : dans une application mobile, un crash est détecté lors de l'authentification via Google Sign-In sur Android 12. Le correctif est effectué dans develop et passe la revue de code. Cependant, la branche de release actuelle v2.5 est déjà en phase de test bêta. Le cherry-pick du commit de correctif de develop vers release/v2.5 permet d'inclure le correctif dans la prochaine release sans transférer les autres modifications qui ne sont pas encore prêtes pour la publication.

Lors de l'utilisation de cherry-pick dans les projets mobiles, il est important de prendre en compte les dépendances : si le correctif affecte des fichiers qui ont été modifiés dans develop après le point de divergence de la branche de release, cherry-pick peut apporter un ensemble incomplet de modifications. Dans de tels cas, il est nécessaire de vérifier que toutes les modifications connexes ont également été transférées, sinon l'application pourrait ne pas compiler ou fonctionner incorrectement. Vérifiez toujours la compilation après cherry-pick avant de pousser les modifications vers la branche partagée.

Cherry-pick vs Merge vs Rebase

Les trois outils principaux d'intégration des modifications dans Git — merge, rebase et cherry-pick — résolvent différentes tâches. Le choix dépend de la quantité de modifications à transférer et de l'aspect souhaité de l'historique.

Merge — lorsque vous devez fusionner deux branches entièrement et conserver les informations de branchement. Rebase — lorsque vous devez mettre à jour une branche personnelle à l'état le plus récent avec un historique propre. Cherry-pick — lorsque vous n'avez besoin que d'un seul commit ou de plusieurs commits sélectionnés.

En pratique, ces outils sont combinés : une fonctionnalité est développée avec un rebase périodique sur develop, puis fusionnée via --no-ff merge, et lorsqu'il est nécessaire de transférer un correctif vers une autre branche, cherry-pick est utilisé. Chaque outil résout sa propre tâche à sa propre étape.

Risques et limitations de Cherry-pick

Cherry-pick est un outil utile mais potentiellement dangereux lorsqu'il est utilisé incorrectement ou de manière excessive. Les principaux risques sont liés à la duplication de commits, à la perte de contexte et aux conflits lors de fusions ultérieures.

• Duplication de commits — si le même commit entre plus tard dans la branche via merge, Git crée un second commit identique dans les modifications. Cela pollue l'historique et complique git bisect
• Perte de contexte — cherry-pick transfère le diff mais ne transfère pas les informations sur les commits parents et les dépendances. Si cherry-pick a appliqué le commit A sans le commit B dont dépendait A, des erreurs logiques peuvent survenir
• Conflits de fusion — après cherry-pick, lors d'une fusion complète de branches, Git peut voir les mêmes modifications deux fois et créer des conflits qui auraient pu être évités avec une fusion normale
• Absence de traçabilité — sans le flag -x, il est impossible de savoir qu'un commit a été transféré depuis une autre branche. Lors de la recherche de l'origine d'une modification, un développeur peut passer des heures à déterminer la provenance du commit

Recommandations pour minimiser les risques : utilisez toujours le flag -x pour indiquer le SHA original, documentez la raison du cherry-pick dans le message du commit, et lorsque c'est possible, utilisez merge au lieu de cherry-pick quand le contexte le permet. Si les cherry-picks deviennent nombreux — envisagez une restructuration des branches.

Vérifications automatisées pour Cherry-pick

Les pipelines CI doivent considérer cherry-pick comme un scénario séparé. Il est recommandé de configurer une vérification automatisée : lorsqu'un commit cherry-pick est créé, le CI vérifie que les fichiers modifiés correspondent à l'ensemble attendu et exécute des tests pour les modules concernés. Cela réduit le risque de régression lors du transfert de modifications entre branches.