Par Anonyme (non vérifié) , 29 avril 2026

Ce que fait cherry-pick

git cherry-pick applique le diff d'un ou plusieurs commits sur la branche actuelle comme nouveaux commits. C'est le bon outil quand vous voulez un changement spécifique sans merger toute la branche — typique pour rétroporter des correctifs vers une branche release ou pour avancer un hotfix.

Usage basique et par plages

git cherry-pick <sha>
git cherry-pick A..B          # exclusif de A, inclusif de B
git cherry-pick A^..B         # inclusif de A et B

Cherry-pick supporte la même syntaxe de plages que git log. Utilisez --no-commit (-n) pour préparer les changements sans commiter — utile pour appliquer plusieurs picks en un seul commit.

Résoudre les conflits

Si un pick entre en conflit, Git s'arrête. Résolvez, préparez et continuez :

git cherry-pick --continue
git cherry-pick --skip
git cherry-pick --abort

Enregistrer la source

Utilisez -x pour ajouter une ligne "(cherry picked from commit ...)" au message :

git cherry-pick -x <sha>

Mainline pour les merges

Faire un cherry-pick d'un commit de merge est ambigu : quel parent fournit la base ? Utilisez -m :

git cherry-pick -m 1 <merge-sha>

Le mainline 1 est généralement la branche qui a reçu le merge.

Piège : histoires divergentes

Cherry-pick crée un nouveau commit avec un SHA différent de l'original. Si les deux branches finissent par fusionner, Git les réconcilie souvent, mais si les deux copies ont divergé via des éditions ultérieures, vous risquez de réappliquer ou d'entrer en conflit. Préférez merger quand l'intégration de toute la branche est désirée.

Piège : dérive sémantique silencieuse

Un cherry-pick textuellement propre peut quand même casser le comportement si le code environnant a changé de sens. Lancez toujours les tests après les picks, surtout entre versions éloignées.

Suivi des picks appliqués

Pour trouver quels commits sur une branche ont été cherry-pickés d'ailleurs, regardez git log --grep="cherry picked from" quand -x a été utilisé. Pour une approche plus rigoureuse, voir git patch-id :

git log -p <sha> | git patch-id
git log -p main | git patch-id

Erreurs courantes

Cherry-pick sans -x sur une branche release maintenue rend les pistes d'audit pénibles. Oublier -m sur un commit de merge produit un pick vide ou un diff confus. En cas de doute, préférez git rebase --onto pour déplacer des séquences de commits entre branches.