LA COPIE, DESSINÉE

Une correction qui vit sur une branche feature ; main la veut maintenant. Le pick rejoue le patch, frappe un SHA neuf, et laisse l'original exactement où il était :

fig — copie, pas déplacement : supprimez la branche feature quand vous voulez ; la copie pickée a son propre SHA et pas de dépendance à l'ancien

LES TROIS ÉTAPES

Trouver le SHA, basculer sur la branche cible, picker — le pick atterrit là où HEAD pointe :

# 1. locate the commit on the source branch
git log feature/payment-fix --oneline -5

# 2. switch to the branch that should receive it
git switch main

# 3. copy it over
git cherry-pick 1a2b3c4

verify: git log -1 --stat → la modification pickée, SHA neuf, sur la branche cible

Deux commodités à connaître : git cherry-pick <branch> pick le tip de cette branche — pratique, mais facile à déclencher par accident avec une image mentale périmée de ce qu'est « le tip ». Et après tout pick, git log -1 --stat confirme ce qui est arrivé : une seconde de lecture, économise un revert.

MULTIPLES COMMITS

Trois formes, dans l'ordre de fréquence souhaité — toutes traversent les branches, puisque les SHA se résolvent contre tout le dépôt :

# 1. explicit list — picked in the order you list them
git cherry-pick 1a2b3c4 5d6e7f8

# 2. range — everything after A up to and including B
git cherry-pick A..B

# 3. range including A
git cherry-pick A^..B

verify: git log --oneline -4 après le pick → les deux commits rejoués dans l'ordre, le plus ancien en premier

La distinction entre A..B et A^..B est la surprise classique : A..B exclut A. Visualisez la plage à partir de git log, prenez oldest..newest, et vous sautez le plus ancien commit en silence — oldest^..newest fait disparaître le décalage de un. Pour replier plusieurs picks en un seul commit au lieu de trois, mettez en stage sans committer avec -n / --no-commit, puis un seul commit :

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

« POURQUOI ÇA NE MARCHE PAS » — LES QUATRE CAUSES

1. Un conflit a arrêté le pick. Git applique le patch, tombe sur une ligne changée des deux côtés, et se met en pause en mi-séquence. Résolvez les fichiers, puis git add <resolved-files> et git cherry-pick --continue — ou --abort pour revenir à l'état d'avant-pick. --continue n'est pas optionnel et pas implicite : tant que vous ne l'avez pas tourné, git status continue de dire You are currently cherry-picking.
2. Le pick est vide (« The previous cherry-pick is now empty ») — le changement existe déjà sur cette branche, souvent venu d'un pick antérieur ou d'un merge squashé. Sautez-le avec git cherry-pick --skip, ou forcez un marqueur vide avec --allow-empty.
3. Le commit est un commit de merge. Un merge a deux parents, donc « applique ce diff » est ambigu — git refuse plutôt que de deviner. Dites contre quel parent vous différenciez : git cherry-pick -m 1 <merge-sha>. Les parents sont numérotés dans l'ordre où git les a enregistrés : parent 1, la branche sur laquelle vous étiez lors du merge ; parent 2, la branche arrivée — -m 1 est presque toujours ce que veut un backport.
4. Mauvais arbre de travail ou HEAD détachée. Le pick atterrit là où HEAD pointe. git branch --show-current avant le pick ; s'il n'imprime rien, vous êtes en HEAD détachée et le commit sera orphelin dès que vous changerez de branche.

PICK VS MERGE VS REBASE

La règle en une ligne : cherry-pick déplace une sélection ; merge et rebase déplacent tout. Tendre vers cherry-pick pour « synchroniser » avec une branche, c'est le signe que vous voulez en fait un merge. Une habitude à éviter : picker le même commit dans plusieurs branches sur la durée — chaque future correction sur la branche source exigera un autre pick, et à la fin les branches dérivent. Les backports vers les branches de release sont un motif normal ; un univers parallèle permanent, non.

LE WORKFLOW, CONDENSÉ

git log <source-branch> --oneline -5   # find the SHA(s)
git switch <target-branch>             # land in the right place
git cherry-pick A^..B                  # range, list, or single SHA
# on conflict: resolve → git add → git cherry-pick --continue
git log -1 --stat                      # confirm what landed

Trouver, basculer, picker, vérifier. La commande a une réputation de danger qu'elle ne mérite pas — le diff s'applique, ou bien ça s'arrête et vous dit pourquoi. La seule erreur vraiment destructrice, c'est picker dans la mauvaise branche, et git log -1 avant de pousser rend celle-ci difficile à rater.

fin de la page pick · rien n'a été téléchargé · tout est local