Git
Français ▾ Topics ▾ Latest version ▾ git-cherry-pick last updated in 2.45.0

NOM

git-cherry-pick - Applique les modifications introduites par certains commits existants

SYNOPSIS

git cherry-pick [--edit] [-n] [-m <numéro-de-parent>] [-s] [-x] [--ff]
		  [-S[<id-clé>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

DESCRIPTION

Étant donné un ou plusieurs commits existants, appliquer la modification que chacun d’eux introduit, en enregistrant un nouveau commit pour chacun. Cela nécessite que votre arbre de travail soit propre (pas de modification depuis le commit HEAD).

Lorsqu’il n’est pas évident de savoir comment appliquer une modification, il se produit ce qui suit :

  1. La branche actuelle et le pointeur HEAD restent au dernier commit effectué avec succès.

  2. La référence CHERRY_PICK_HEAD est définie pour pointer vers le commit qui a introduit la modification difficile à appliquer.

  3. Les chemins dans lesquels la modification s’est appliquée proprement sont mis à jour à la fois dans le fichier d’index et dans votre arbre de travail.

  4. Pour les chemins conflictuels, le fichier d’index enregistre jusqu’à trois versions, comme décrit dans la section "VRAIE FUSION" de git-merge[1]. Les fichiers de l’arbre de travail incluront une description du conflit encadrée par les marqueurs de conflit habituels <<<<<<< et >>>>>>>.

  5. Aucune autre modification n’est apportée.

Voir git-merge[1] pour quelques conseils sur la résolution de tels conflits.

OPTIONS

<commit>…​

Les commits à picorer. Pour une liste plus complète des façons d’épeler les commits, voir gitrevisions[7]. Des ensembles de commits peuvent être passés mais aucune traversée n’est faite par défaut, comme si l’option --no-walk était spécifiée, voir git-rev-list[1]. Notez que la spécification d’une plage alimentera tous les arguments <commit>…​ à un seul parcours de révision (voir un exemple plus bas qui utilise maint master…​next).

-e
--edit

Avec cette option, git cherry-pick vous permettra de modifier le message de validation avant de valider.

--cleanup=<mode>

Cette option détermine comment le message de valiation sera nettoyé avant d’être transmis à la machine de commit. Voir git-commit[1] pour plus de détails. En particulier, si la valeur de <mode> est scissors, les ciseaux seront ajoutés à MERGE_MSG avant d’être transmis dans le cas d’un conflit.

-x

Lors de l’enregistrement du commit, ajouter une ligne qui ajoute "(cherry pick from commit …​)" au message de commit original afin d’indiquer de quel commit ce changement a été picoré. Ceci est fait uniquement pour les picorages sans conflits. N’utilisez pas cette option si vous faites du picorage depuis votre branche privée car l’information est inutile pour le destinataire. En revanche, si vous faites du picorage entre deux branches visibles publiquement (par exemple, le rétroportage d’un correctif dans une branche de maintenance d’une ancienne version à partir d’une branche de développement), l’ajout de cette information peut être utile.

-r

Avant, la commande faisait par défaut -x comme décrit ci-dessus, et -r permettait de la désactiver. Maintenant, le défaut est de ne pas faire -x, donc cette option est un no-op.

-m <numéro-de-parent>
--mainline <numéro-de-parent>

Habituellement, vous ne pouvez pas picorer une fusion parce que vous ne savez pas quel côté de la fusion doit être considéré comme la ligne principale. Cette option spécifie le numéro du parent (à partir de 1) de la ligne principale et permet à cherry-pick de rejouer la modification par rapport au parent spécifié.

-n
--no-commit

Habituellement, la commande crée automatiquement une séquence de commits. Cette option applique les changements nécessaires pour sélectionner chaque commit nommé à votre arbre de travail et à l’index, sans faire aucun commit. De plus, lorsque cette option est utilisée, votre index ne doit pas nécessairement correspondre au commit HEAD. Le picorage est fait par rapport à l’état initial de votre index.

Ceci est utile pour picorer l’effet de plusieurs commits sur votre index à la suite.

-s
--signoff

Ajouter une ligne terminale Signed-off-by au message de commit. Référez-vous à l’option de contre-signature dans git-commit[1] pour plus d’information.

-S[<idclé>]
--gpg-sign[=<idclé>]
--no-gpg-sign

Signer les commits avec GPG. L’argument idclé est optionnel avec par défaut l’identité du validateur ; si spécifiée, elle doit être collée à l’option sans aucun espace. --no-gpg-sign est utile pour annuler l’effet de la variable de configuration commit.gpgSign ainsi que tout --gpg-sign précédent.

--ff

Si le HEAD actuel est le même que le parent du commit picoré, alors une avance rapide sur ce commit sera effectuée.

--allow-empty

Par défaut, le picorage d’un commit vide échouera, indiquant qu’une invocation explicite de git commit --allow-empty est nécessaire. Cette option surcharge ce comportement, permettant aux commits vides d’être préservés automatiquement dans un picorage. Notez que lorsque "--ff" est en vigueur, les commits vides qui répondent à l’exigence d'"avance rapide" seront conservés même sans cette option. Notez également que l’utilisation de cette option ne conserve que les commits qui étaient initialement vides (c’est-à-dire que le commit a enregistré le même arbre que son parent). Les commits qui sont rendus vides à cause d’un commit précédent feront échouer le picorage. Pour forcer l’inclusion de ces commits, utilisez --empty=keep.

--allow-empty-message

Par défaut, le picorage d’un commit avec un message vide échouera. Cette option annule ce comportement, permettant aux commits avec des messages vides d’être picorés.

--empty=(drop|keep|stop)

Comment manipuler les commits picorés qui sont redondants avec les modifications déjà dans l’historique actuel.

drop

Le commit sera abandonné.

keep

Le commit sera gardé. Implique --allow-empty.

stop

La picorage s’arrêtera lorsque le commit sera appliqué, vous permettant d’examiner le commit. C’est le comportement par défaut.

Notez que --empty=drop et --empty=stop spécifient seulement comment manipuler un commit qui n’était pas initialement vide, mais est devenu vide en raison d’un commit précédent. Les commits qui étaient initialement vides causeront encore l’échec du picorage à moins que --empty=keep ou --allow-empty ne soient spécifiés.

--keep-redundant-commits

Synonyme obsolète pour --empty=keep.

--strategy=<strategie>

Utilise la stratégie de fusion donnée. Ne devrait être utilisée qu’une seule fois. Voir la section STRATÉGIES DE FUSION dans git-merge[1] pour plus de détails.

-X<option>
--strategy-option=<option>

Passer l’option spécifique de stratégie de fusion à la stratégie de fusion. Voir git-merge[1] pour plus de détails.

--rerere-autoupdate
--no-rerere-autoupdate

Après que le mécanisme rerere réutilise une résolution enregistrée sur le conflit actuel pour mettre à jour les fichiers dans l’arbre de travail, lui permettre de mettre également à jour l’index avec le résultat de la résolution. --no-rerere-autoupdate est un bon moyen de revérifier ce que rerere a fait et de détecter des erreurs de fusion potentielles, avant de valider le résultat dans l’index avec un git add séparé.

SOUS-COMMANDES DU SÉQUENCEUR

Warning

Missing fr/sequencer.txt

See original version for this content.

EXEMPLES

git cherry-pick master

Applique la modification introduite par le commit au sommet de la branche master et créer un nouveau commit avec cette modification.

git cherry-pick ..master
git cherry-pick ^HEAD master

Applique les modifications introduites par tous les commits qui sont des ancêtres de master mais pas de HEAD pour produire de nouveaux commits.

git cherry-pick maint next ^master
git cherry-pick maint master..next

Applique les modifications introduites par tous les commits qui sont des ancêtres de maint ou next, mais pas master ni aucun de ses ancêtres. Notez que ce dernier ne signifie pas maint et tout ce qui se trouve entre master et next ; spécifiquement, maint ne sera pas utilisé s’il est inclus dans master.

git cherry-pick master~4 master~2

Applique les modifications introduites par les cinquième et troisième derniers commits pointés par master et crée 2 nouveaux commits avec ces modifications.

git cherry-pick -n master~1 next

Applique à l’arbre de travail et à l’index les modifications introduites par l’avant-dernier commit pointé par master et par le dernier commit pointé par next, mais ne crée aucun commit avec ces modifications.

git cherry-pick --ff ..next

Si l’historique est linéaire et que HEAD est un ancêtre de next, met à jour l’arbre de travail et avance le pointeur HEAD pour qu’il corresponde à next. Sinon, applique les modifications introduites par les commits qui sont dans next mais pas HEAD à la branche courante, en créant un nouveau commit pour chaque nouvelle modification.

git rev-list --reverse master -- README | git cherry-pick -n --stdin

Applique les modifications introduites par tous les commits de la branche master qui ont touché README, à l’arbre de travail et à l’index, afin que le résultat puisse être inspecté et transformé en un seul nouveau commit si cela convient.

La séquence suivante tente de rétro-porter une rustine, échoue parce que le code auquel la rustine s’applique a trop changé, puis réessaie, cette fois en faisant plus attention à la correspondance des lignes de contexte.

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git cherry-pick --abort            (3)
$ git cherry-pick -Xpatience topic^  (4)
  1. applique la modification qui serait montrée par git show topic^. Dans cet exemple, la rustine ne s’applique pas proprement, donc l’information sur le conflit est écrite dans l’index et l’arbre de travail et aucun nouveau commit n’en résulte.

  2. résume les modifications à réconcilier

  3. annule le picorage. En d’autres termes, retourne à l’état antérieur à l’extraction, en préservant toutes les modifications locales précédentes dans l’arbre de travail.

  4. essaie d’appliquer à nouveau la modification introduite par topic^, en passant du temps supplémentaire pour éviter les erreurs basées sur des lignes de contexte déterminées incorrectement.

VOIR AUSSI

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .

scroll-to-top