git cherry-pick

Branches et fusions

Appliquer les modifications de commits précis sur la branche courante

La commande 'git cherry-pick' applique les modifications introduites par un ou plusieurs commits existants sur la branche courante, en créant un nouveau commit pour chacun. Contrairement à merge ou rebase, qui travaillent sur des branches entières, cherry-pick permet de copier des commits précis de façon sélective. C’est précieux pour reporter des hotfixes sur des branches de release, récupérer des commits perdus ou apporter certaines fonctionnalités d’une branche à une autre sans tout fusionner. Chaque commit cherry-pické reçoit un nouveau SHA - c’est une copie, pas un déplacement. Cherry-pick est chirurgical et précis : vous contrôlez finement quelles modifications arrivent sur votre branche.

Synopsis

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff] [-S[<keyid>]] <commit>...
git cherry-pick (--continue | --skip | --abort | --quit)
[ ] facultatif| ou<arg> valeur à remplacer... répétable--flag option

Options

Cliquez sur une option pour la déplier

Débutant (2)

Appliquer les modifications au répertoire de travail et à l’index sans créer de commit. Parfait pour regrouper plusieurs cherry-picks en un seul commit.

Si nécessaireRéunir plusieurs cherry-picks en un seul commit

Exemple

git cherry-pick -n abc1234

Ouvrir l’éditeur pour modifier le message avant de committer. À utiliser pour expliquer pourquoi le commit a été cherry-pické.

Si nécessaireAjoute du contexte au message du commit copié

Exemple

git cherry-pick -e abc1234

Intermédiaire (5)

Reprendre le cherry-pick après avoir résolu les conflits. Il faut d’abord indexer les fichiers résolus avec 'git add'.

RecommandéReprend après que vous avez résolu et préparé les conflits

Exemple

git cherry-pick --continue

Annuler l’opération de cherry-pick et remettre la branche dans son état d’avant. À utiliser quand les conflits sont trop complexes ou que vous avez pris le mauvais commit.

RecommandéAnnule sans risque et rétablit l’état d’avant le cherry-pick

Exemple

git cherry-pick --abort

Sauter le commit courant et continuer avec les commits restants de la séquence. Les modifications du commit sauté ne sont PAS appliquées.

Si nécessaireSaute un commit dont vous n’avez plus besoin des modifications

Exemple

git cherry-pick --skip

Ajouter '(cherry picked from commit ...)' au message du commit. Aide à retrouver l’origine des commits cherry-pickés.

RecommandéEnregistre le commit d’origine — essentiel pour les reports de correctifs

Exemple

git cherry-pick -x abc1234

Ajouter un trailer 'Signed-off-by' avec votre nom et votre e-mail. Exigé par certains projets pour des raisons légales ou d’audit.

Si nécessaireSeulement si le projet exige des lignes Signed-off-by

Exemple

git cherry-pick -s abc1234

Avancé (2)

Garder les commits qui étaient vides dès le départ (même arbre que leur parent). Les commits qui deviennent vides parce que leurs modifications existent déjà arrêtent quand même l’opération ; utilisez --empty=keep pour ceux-là.

Si nécessaireSeulement pour les commits qui étaient vides dès le départ

Exemple

git cherry-pick --allow-empty abc1234

Obligatoire pour cherry-picker des commits de fusion. Indique quel parent (1 ou 2) est la ligne principale. En général -m 1 pour obtenir les modifications de la branche fusionnée.

Si nécessaireObligatoire pour les commits de fusion ; en général -m 1

Exemple

git cherry-pick -m 1 abc1234

Expert (2)

Utiliser la stratégie de fusion indiquée pour appliquer les modifications. Par défaut 'ort' (ou 'recursive' sur les anciens Git). Pas de forme courte : ici -s veut dire --signoff.

DéconseilléLa stratégie ort par défaut est presque toujours la bonne

Exemple

git cherry-pick --strategy=ort abc1234

Passer des options à la stratégie de fusion. Courantes : 'theirs' (favoriser les modifications prises), 'ours' (favoriser l’actuel), 'patience' (meilleurs diffs).

Déconseillé-Xours / -Xtheirs jettent sans rien dire un côté des hunks en conflit

Exemple

git cherry-pick -Xtheirs abc1234

Choisir la bonne option

Comparer git cherry-pick aux commandes voisines

Savoir quand utiliser cherry-pick plutôt que merge, rebase ou revert

CommandeAspectCherry-pickAutre commande
ScopeSeulement certains commitsMerge : toute la branche / Rebase : toute la branche
Creates new commitsOui - nouveau SHA, même contenuMerge : commit de fusion / Rebase : réécrit tout
Original staysOui - l’original n’est pas touchéMerge : oui / Rebase : orphelin
Use caseBackport, report sélectifIntégrer des branches complètes
History effectCrée des modifications en doublePréserve ou rend linéaire
ConflictsPar commit pendant le pickAu point de fusion ou par commit du rebase

Exemples de workflows

1
git checkout release-1.0

Passer sur la branche de release

2
git log main --oneline

Trouver le hash du commit du correctif

3
git cherry-pick -x abc123

Appliquer le correctif avec la référence d’origine

4
git push origin release-1.0

Pousser le correctif reporté

1
git checkout main

Passer sur la branche main

2
git log feature --oneline

Relire les commits de la branche de fonctionnalité

3
git cherry-pick abc123 def456

Ne prendre que les commits prêts

4
git push origin main

Pousser les commits choisis

1
git reflog

Trouver le hash du commit dans le reflog

2
git checkout main

Passer sur la branche cible

3
git cherry-pick abc123

Appliquer le commit orphelin

1
git checkout target-branch

Passer sur la branche de destination

2
git cherry-pick A^..C

Appliquer les commits A à C (inclus)

3
git log --oneline

Vérifier que les commits ont été appliqués

Dépannage

"commit is a merge but no -m option was given"

Cause : Vous essayez de cherry-picker un commit de fusion sans préciser quel parent

Utilisez -m 1 ou -m 2 pour préciser le parent de la ligne principale

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

Conflits pendant un cherry-pick

Cause : Les modifications entrent en conflit avec votre branche courante

Résolvez les conflits dans les fichiers, faites git add, puis git cherry-pick --continue. Ou abandonnez avec --abort

git add <resolved-files> && git cherry-pick --continue

"The previous cherry-pick is now empty"

Cause : Les modifications du commit existent déjà dans votre branche

Lancez 'git commit --allow-empty' pour l’enregistrer quand même, ou 'git cherry-pick --skip' pour le sauter

git cherry-pick --skip

Le cherry-pick a créé des commits en double

Cause : Les mêmes modifications existent maintenant sous forme de commits différents sur des branches différentes

C’est le comportement attendu. Utilisez l’option -x pour documenter le lien

git cherry-pick -x <commit>

Le mauvais commit a été cherry-pické

Cause : Vous avez pris le mauvais SHA de commit

S’il n’est pas poussé : git reset --hard HEAD~1. S’il est poussé : git revert du commit cherry-pické

git reset --hard HEAD~1

Le cherry-pick semble sans effet

Cause : Le commit est peut-être vide ou ses modifications déjà appliquées

Regardez git diff HEAD~1 pour voir les modifications réelles

git diff HEAD~1

Astuces et pièges

Bonnes pratiques

  • ✓Utilisez -x pour les backports afin d’ajouter la référence '(cherry picked from commit ...)' au message de commit
  • ✓Faites les cherry-picks dans l’ordre chronologique - les commits dépendants doivent être appliqués du plus ancien au plus récent pour éviter les conflits
  • ✓Préférez merge pour les branches partagées - cherry-pick crée des commits en double alors que merge préserve l’historique
  • ✓Testez après un cherry-pick - le commit peut fonctionner dans son contexte d’origine mais échouer dans le nouveau
  • ✓Documentez les cherry-picks dans les messages de commit avec l’option -e pour expliquer pourquoi le commit a été copié
  • ✓Utilisez --no-commit pour regrouper des picks liés en un seul commit plus propre
  • ✓Pensez à git cherry plutôt qu’à log pour trouver les commits pas encore appliqués
  • ✓Lors d’un backport, incluez toujours le hash du commit d’origine dans le message pour la traçabilité

Erreurs fréquentes

  • ✗Oublier -m pour les commits de fusion. Cherry-picker un commit de fusion sans '-m 1' ou '-m 2' échoue - il faut préciser par rapport à quel parent calculer le diff.
  • ✗Ne pas indexer les fichiers résolus avant --continue. Il faut lancer 'git add' sur les fichiers résolus avant 'git cherry-pick --continue'.
  • ✗S’attendre au même hash de commit. Cherry-pick crée de NOUVEAUX commits avec de nouveaux SHA - il copie des modifications, il ne déplace pas de commits.
  • ✗Cherry-picker des commits déjà appliqués. Cela provoque des conflits ou des commits vides - vérifiez d’abord avec 'git log'.
  • ✗Choisir les commits dans le mauvais ordre. Les commits dépendants doivent être pris du plus ancien au plus récent, sinon vous aurez des conflits.
  • ✗Cherry-picker sur des branches publiques crée des commits en double quand d’autres ont l’original - préférez merge pour les branches partagées.

FAQ

A:

Non. Cherry-pick crée un NOUVEAU commit avec les mêmes modifications mais un SHA différent. Le commit d’origine reste où il était.

A:

Le hash d’un commit Git dépend du contenu, du parent, de l’auteur, de la date et du message. Cherry-pick garde l’auteur et la date d’auteur, mais le parent et la date du committer changent, donc le hash change même si les modifications sont identiques.

A:

Oui ! Listez-les : git cherry-pick A B C, ou utilisez des plages : git cherry-pick A^..C (inclut A et C).

A:

Utilisez l’option -m : git cherry-pick -m 1 <merge-commit>. Le nombre indique quel parent est la ligne principale (en général 1).

A:

A..B exclut A (les commits après A jusqu’à B). A^..B inclut A (les commits de A à B inclus).

A:

S’il n’est pas poussé : git reset --hard HEAD~1. S’il est poussé : git revert <commit> pour créer un commit d’annulation.

A:

Cherry-pick pour des commits précis. Rebase pour déplacer des branches entières. Si vous avez besoin de la plupart des commits d’une branche, rebase est plus propre.