mrsaynothing.dev
Git cherry-pick : une copie, jamais un déplacement
Un commit isolé, une plage qui inclut son début, le conflit en mi-séquence — et la ligne pick vs merge vs rebase qui clôt le débat.
git cherry-pick <sha> copie un commit — même patch, nouveau SHA, rien ne bouge.
Une plage exclut son début : A^..B inclut A, A..B le saute en silence.
Bloqué sur un conflit ? Résolvez, git add, git cherry-pick --continue — d'ici là vous êtes en mi-séquence.
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 1a2b3c4verify: 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^..Bverify: 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
- 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>etgit cherry-pick --continue— ou--abortpour revenir à l'état d'avant-pick.--continuen'est pas optionnel et pas implicite : tant que vous ne l'avez pas tourné,git statuscontinue de dire You are currently cherry-picking. - 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. - 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 1est presque toujours ce que veut un backport. - Mauvais arbre de travail ou HEAD détachée. Le pick atterrit là où HEAD pointe.
git branch --show-currentavant 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
| Commande | Ce qui arrive sur la cible | Histoire | Quand l'utiliser |
|---|---|---|---|
git cherry-pick <sha> | Commit(s) nommé(s) seulement | Copie, nouveaux SHA | Une correction précise doit bouger maintenant |
git merge <branch> | Tout ce qui est sur la branche | Commit de merge ou fast-forward | Vous voulez toute la branche, divergence visible |
git rebase <base> | Tous les commits de la branche, rejoués | Linéaire, SHA réécrits | Vous voulez la branche comme une course linéaire propre |
git revert <sha> | Inverse d'un commit | Ajoute un commit d'undo | Un commit arrivé doit être annulé sur une histoire partagée |
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 landedTrouver, 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.
A..B exclut A), le comportement pick-vide et la -m numérotation des parents sont le comportement documenté de git, tapés depuis des picks qui ont vraiment atterri.fin de la page pick · rien n'a été téléchargé · tout est local