Le cherry-pick : quand il convient et ce qu'il coûte à l'historique

Ce que c'est

git cherry-pick <commit> applique la modification qu'introduit un commit par-dessus la branche courante et enregistre un nouveau commit. La documentation exige un arbre de travail propre, s'arrête sur les conflits avec CHERRY_PICK_HEAD défini jusqu'à --continue, --skip ou --abort, et propose -x pour ajouter une ligne « (cherry picked from commit ...) » au message. Le cherry-pick d'un commit de fusion nécessite -m <parent-number> pour indiquer quel parent constitue la ligne principale. -n / --no-commit applique plusieurs cherry-picks dans l'index avant un seul commit.

Pourquoi c'est important

Le nouveau commit porte le même correctif mais un identifiant et un parent différents. Git compare les commits par ascendance, si bien qu'une fusion ultérieure de la branche source ne sait pas que la modification est déjà présente : une modification identique des deux côtés fusionne généralement sans problème, mais la moindre différence (un conflit résolu pendant le cherry-pick, une modification ultérieure des mêmes lignes) devient un conflit, et l'historique conserve de toute façon deux commits pour une seule modification. Chaque cherry-pick ajoute donc un petit coût permanent : un historique qui doit être réconcilié par le contenu du correctif plutôt que par l'ascendance. git log --cherry-pick --left-right A...B existe précisément pour omettre les commits qui introduisent la même modification de l'autre côté, comme le décrit la documentation de git-log.

Comment l'appliquer

• Rétroportage d'un correctif : committer le correctif sur la branche supportée la plus ancienne et fusionner vers le haut, ou le cherry-picker vers le bas avec -x afin que l'origine reste traçable. La documentation recommande -x pour les cherry-picks entre branches publiques et le déconseille pour les branches privées.
• Récupération d'un bon commit isolé d'une branche destinée à être abandonnée : le cherry-picker, puis supprimer la branche pour qu'aucune lignée en double ne subsiste.
• Souhait d'obtenir une branche entière : la fusionner ou la rebaser. Cherry-picker chaque commit d'une branche produit une seconde lignée des mêmes modifications qu'une fusion ultérieure ne peut pas reconnaître comme déjà intégrée.
• Correctif d'urgence publié depuis une branche de release : le cherry-picker immédiatement vers main, avant que les deux ne divergent davantage.
• Garder les commits cherry-pickés petits et autonomes ; le cherry-pick de la moitié d'une refactorisation entre en conflit avec l'autre moitié par la suite.

Pièges

Le cherry-pick d'un commit qui dépend de commits antérieurs non cherry-pickés compile par chance ou pas du tout. La résolution de conflit pendant un cherry-pick n'est enregistrée nulle part ailleurs que dans le nouveau commit. Faire un bisect sur une branche composée de cherry-picks pointe vers la copie, pas vers la discussion d'origine, sauf si des lignes -x sont présentes. Des cherry-picks répétés entre branches à longue durée de vie sont le signe que c'est le modèle de branchement, pas l'outil, qu'il faut changer.