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).

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

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.

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.

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.

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é.

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.

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.

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.

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

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.

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.

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

Synonyme obsolète pour --empty=keep.

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.

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

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é.

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

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

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.

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.

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.

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.

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.