infra / git-github
Cherry-pick
Explication
Ce que vous allez apprendre
- Comprendre pourquoi le cherry-pick copie un commit plutôt que de le déplacer
- Appliquer un commit précis d'une branche vers une autre avec
git cherry-pick - Reconnaître le scénario type du "backport" d'un correctif de sécurité
- Gérer un conflit pendant un cherry-pick exactement comme pour un merge
- Utiliser
--no-commitpour ajuster un cherry-pick avant de le valider
Dans quel contexte ?
Une faille de sécurité XSS est corrigée sur la branche develop du projet boutique-api, dans le commit a1b2c3d. Cette même faille existe aussi sur main, déjà déployée en production, mais develop contient aussi d'autres fonctionnalités pas encore prêtes qu'on ne veut surtout pas déployer. Le cherry-pick permet d'appliquer uniquement ce commit de correctif sur main, sans toucher au reste de develop.
Ce que merge et rebase ne permettent pas de faire finement
D'abord, le merge et le rebase, vus précédemment, intègrent l'intégralité d'une branche, tous ses commits, dans l'ordre.
Un besoin plus ciblé
Mais parfois, on ne veut qu'un seul commit précis venant d'une branche, sans tout le reste, typiquement un correctif de sécurité urgent qui doit aussi être appliqué immédiatement sur la branche de production.
L'outil conçu pour ce besoin
Le cherry-pick répond exactement à ce besoin ciblé.
Ce qu'il fait techniquement
Il faut bien comprendre ce que fait un cherry-pick : il ne "déplace" rien, il copie le contenu d'un commit existant et crée un tout nouveau commit, avec un nouvel identifiant, sur la branche courante.
Ce que ça donne concrètement
Les deux commits, original et copié, coexistent alors, chacun sur sa branche, avec le même contenu mais des identités différentes. C'est similaire dans l'esprit à ce que fait le rebase, mais appliqué à un seul commit choisi.
Un usage emblématique : le backport de correctif
Le scénario le plus typique du cherry-pick est le "backport" : un bug est corrigé sur la branche de développement principale, mais ce même correctif doit aussi être appliqué à une ancienne version encore maintenue en production.
Pourquoi cherry-pick plutôt que refaire à la main
Plutôt que de refaire le correctif à la main sur l'autre branche, sans y intégrer les autres fonctionnalités pas encore prêtes, le cherry-pick le réplique fidèlement en une commande.
| Opération | Ce qui est intégré | Résultat sur les SHA |
|---|---|---|
merge | Tous les commits de la branche | Historique original préservé |
cherry-pick | Un seul commit choisi | Nouveau SHA pour la copie |
Bonne pratique
Utilise --no-commit quand tu cherry-pickes un commit sur un contexte de code différent de l'original : cela te laisse le temps de vérifier et d'ajuster avant de valider, plutôt que de créer directement un commit potentiellement incohérent.
Des conflits possibles, comme pour un merge
Puisqu'un cherry-pick applique un changement sur un contexte de code potentiellement différent, un conflit peut survenir exactement comme lors d'un merge classique.
La même procédure de résolution s'applique
Les mêmes marqueurs, la même procédure de résolution avec add puis --continue, ou la possibilité d'annuler proprement avec --abort si la situation devient trop confuse.
Maintenant que tu sais piocher un commit précis, la leçon suivante t'apprend à interroger l'historique plus finement, et même à retrouver automatiquement l'origine d'un bug avec git bisect.
Commandes & code
Cherry-pick
Applique UN commit précis d'une branche sur une autre, sans fusionner tout le reste.
# Cas typique : un correctif urgent fait sur "develop" doit aussi aller sur "main" (déjà en prod)
git log develop --oneline
# a1b2c3d Fix XSS vulnerability in comment form
# e4f5g6h Add new dashboard widget (pas encore prêt pour la prod)
git switch main
git cherry-pick a1b2c3d# Cherry-pick de plusieurs commits, dans l'ordre
git cherry-pick a1b2c3d e4f5g6h
# Plage de commits (EXCLUT le premier, INCLUT le dernier)
git cherry-pick a1b2c3d..h7i8j9k
# Sans créer de commit immédiatement (le temps de vérifier/amender avant de valider)
git cherry-pick --no-commit a1b2c3d
git status
git commit -m "Fix XSS vulnerability (backported from develop)"# Gestion des conflits, identique au merge/rebase
git cherry-pick a1b2c3d
# CONFLICT (content): Merge conflict in comment-form.js
# ... résoudre les marqueurs <<<<<<< ... ======= ... >>>>>>> ...
git add comment-form.js
git cherry-pick --continue
git cherry-pick --abort # annule proprement si besoin# Cherry-pick d'un commit de merge : préciser quel parent sert de référence
git cherry-pick -m 1 <sha-du-merge-commit>Résumé
- Cherry-pick copie UN commit précis vers la branche courante, avec un nouveau SHA.
- Idéal pour porter un hotfix vers plusieurs branches (ex:
develop->main) sans tout fusionner. --no-commitlaisse le temps d'ajuster avant de valider le commit résultant.- Sur un commit de merge,
-m 1précise le parent servant de diff de référence.
Exercices pratiques
Mission : backporter un correctif de sécurité sans tout embarquer
Objectif : Appliquer un seul commit précis d'une branche vers une autre, sans intégrer des fonctionnalités pas encore prêtes.
Contexte
Une faille XSS est corrigée sur develop dans le commit a1b2c3d, entouré d'autres commits ajoutant des fonctionnalités non prêtes pour la production. Cette même faille existe sur main, déjà déployée en production.