Réponses:
Cherry picking dans Git signifie choisir un commit dans une branche et l'appliquer sur une autre.
Ceci est en contraste avec d'autres manières telles que merge
et rebase
qui appliquent normalement de nombreux commits sur une autre branche.
Assurez-vous que vous êtes sur la branche à laquelle vous souhaitez appliquer le commit.
git checkout master
Exécutez ce qui suit:
git cherry-pick <commit-hash>
NB:
Si vous choisissez parmi une branche publique, vous devriez envisager d'utiliser
git cherry-pick -x <commit-hash>
Cela générera un message de validation standardisé. De cette façon, vous (et vos collègues) pouvez toujours garder une trace de l'origine du commit et éviter à l'avenir des conflits de fusion.
Si vous avez des notes attachées au commit, elles ne suivent pas la sélection. Pour les amener également, vous devez utiliser:
git notes copy <from> <to>
Liens supplémentaires:
git cherry-pick -x <commit-hash>
. Cela générera un message de validation standardisé. De cette façon, vous (et vos collègues) pouvez toujours garder une trace de l'origine du commit et éviter à l'avenir des conflits de fusion.
git notes copy <from> <to>
.
"cherry-pick commit applies the changes introduced by the named commit on the current branch"
plus ppl a tendance à considérer le commit comme des changements (comme svn était iirc), mais ce n'est pas le cas, chaque commit fait référence à l'arborescence de travail complète. Bien que cela ne fasse aucune différence dans ce cas, cela peut aider à comprendre pourquoi git fonctionne comme il le fait.
Cette citation est tirée de; Contrôle de version avec Git (livre vraiment génial, je vous encourage à l'acheter si vous êtes intéressé par git)
Edit: Étant donné que cette réponse fait toujours bonne impression, je voudrais ajouter un très joli didacticiel vidéo en action à ce sujet:
Youtube: Introduction à Git Cherry-Pick
Utilisation de git cherry-pick La commande git cherry-pick commit applique les changements introduits par le commit nommé sur la branche courante. Il introduira un nouveau commit distinct. À strictement parler, l'utilisation de git cherry-pick ne modifie pas l'historique existant dans un référentiel; au lieu de cela, il ajoute à l'histoire. Comme pour les autres opérations Git qui introduisent des modifications via le processus d'application d'un diff, vous devrez peut-être résoudre les conflits pour appliquer pleinement les modifications de la validation donnée . La commande git cherry-pick est généralement utilisée pour introduire des validations particulières d'une branche dans un référentiel sur une branche différente. Une utilisation courante consiste à transmettre ou à rétrospecter les commits d'une branche de maintenance à une branche de développement.
$ git checkout rel_2.3
$ git cherry-pick dev~2 # commit F, above
avant:
après:
La sélection de cerises dans Git est conçue pour appliquer une validation d'une branche à une autre. Cela peut être fait si vous par exemple. fait une erreur et commis un changement dans une mauvaise branche, mais ne souhaitez pas fusionner la branche entière. Vous pouvez simplement par exemple. annuler le commit et le sélectionner sur une autre branche.
Pour l'utiliser, vous avez juste besoin git cherry-pick hash
, où hash
est un hachage de validation d'une autre branche.
Pour la procédure complète, voir: http://technosophos.com/2009/12/04/git-cherry-picking-move-small-code-patches-across-branches.html
Petit exemple de situation, lorsque vous avez besoin d'un choix de cerise
Envisagez le scénario suivant. Vous avez deux branches.
a) release1 - Cette branche va à votre client, mais il y a encore quelques bugs à corriger.
b) master - Branche master classique, où vous pouvez par exemple ajouter des fonctionnalités pour release2.
MAINTENANT : Vous réparer quelque chose dans RELEASE1 . Bien sûr, vous avez également besoin de ce correctif dans Master . Et c'est un cas d'utilisation typique pour la cueillette des cerises. Donc, cerise sur le gâteau dans ce scénario signifie que vous prenez un commit de la branche release1 et que vous l'incluez dans la branche master .
cherry-pick est une fonctionnalité de Git. Si quelqu'un veut valider des validations spécifiques dans une branche vers une branche cible, alors le choix de cerise est utilisé.
Les étapes de git cherry-pick sont les suivantes.
git cherry-pick <commit id>
Ici, l'ID de validation est l'ID d'activité d'une autre branche.
git cherry-pick 9772dd546a3609b06f84b680340fb84c5463264f
J'ai préparé des illustrations étape par étape de ce que fait la sélection de cerises - et une animation de ces illustrations (vers la fin).
git cherry-pick feature~2
feature~2
est le 2 e commit avant feature
, c'est-à-dire le commit L
):
Remarque:
Le commit L'
est du point de vue de l'utilisateur (commit = snapshot) la copie exacte du commitL
.
Techniquement (en interne), il s'agit d'un nouveau commit différent (car par exemple L
contient un pointeur vers K
(comme son parent), tandis qu'il L'
contient un pointeur vers E
).
Vous pouvez penser si un choix de cerise ressemble à un rebase, ou plutôt il est géré comme un rebase. Par cela, je veux dire qu'il prend un commit existant et le régénère en prenant, comme point de départ, le chef de la branche sur laquelle vous vous trouvez actuellement.
A rebase
prend un commit qui avait un parent X et régénère le commit comme s'il avait réellement un parent Y, et c'est précisément ce que cherry-pick
fait a.
Le choix de cerise est plus sur la façon dont vous sélectionnez les commits. Avec pull
(rebase), git régénère implicitement vos commits locaux en plus de ce qui est tiré dans votre branche, mais aveccherry-pick
vous choisissez explicitement des validations, et régénérez-les implicitement au-dessus de votre branche actuelle.
Donc, la façon dont vous le faites diffère, mais sous le capot, ce sont des opérations très similaires - la régénération des commits.
cherry-pick
se comporte comme il le fait lorsque la branche cible est fusionnée par la suite dans la branche source. Merci Monsieur.
C'est un peu comme copier (de quelque part) et coller (vers quelque part), mais pour des commits spécifiques.
Si vous souhaitez effectuer un correctif, par exemple, vous pouvez utiliser la cherry-pick
fonction.
Faites votre cherry-pick
dans une branche de développement et merge
engagez-vous dans une branche de publication. De même, effectuez une opération cherry-pick
depuis une branche de publication vers master. Voila
Lorsque vous travaillez avec une équipe de développeurs sur un projet, la gestion des changements entre plusieurs branches git peut devenir une tâche complexe. Parfois, vous ne voulez pas fusionner une branche entière dans une autre et vous n'avez qu'à choisir un ou deux commits spécifiques. Ce processus est appelé «cueillette des cerises».
Trouvé un excellent article sur la cueillette des cerises, consultez-le pour plus de détails: https://www.previousnext.com.au/blog/intro-cherry-picking-git
Si vous souhaitez fusionner sans ID de validation, vous pouvez utiliser cette commande
git cherry-pick master~2 master~0
La commande ci-dessus fusionnera les trois derniers commits de master de 1 à 3
Si vous voulez le faire pour un commit unique, supprimez simplement la dernière option
git cherry-pick master~2
De cette façon, vous fusionnerez le 3e commit à partir de la fin du master.
Il appliquera un commit particulier à votre branche actuelle.
Ça signifie :
Ex: pensez à valider A
added newFileA
modified main:
+ import './newFileA'
commit B
added newFileB
modified main:
+ import './newFileB'
Si vous choisissez le commit B sur une autre branche, vous vous retrouverez avec:
/newFileB
/main :
import './newFileA'
import './newFileB'
puisque la validation B contient newFileB et main , mais pas de newFileA , ce qui entraîne un bogue, donc utilisez-le avec prudence.
Extrait des documents officiels:
Étant donné une ou plusieurs validations existantes, appliquez le changement que chacune introduit, en enregistrant une nouvelle validation pour chacune. Cela nécessite que votre arborescence de travail soit propre (aucune modification de la validation HEAD).
Lorsqu'il n'est pas évident de savoir comment appliquer une modification, les événements suivants se produisent:
La branche actuelle et le pointeur HEAD restent sur la dernière validation effectuée avec succès.
La référence CHERRY_PICK_HEAD est définie pour pointer sur la validation qui a introduit la modification difficile à appliquer.
Les chemins dans lesquels la modification appliquée proprement sont mis à jour à la fois dans le fichier d'index et dans votre arborescence de travail.
Pour les chemins conflictuels, le fichier d'index enregistre jusqu'à trois versions, comme décrit dans la section "TRUE MERGE" de git-merge. Les fichiers de l'arborescence de travail comprendront une description du conflit entre crochets par les marqueurs de conflit habituels <<<<<<< et >>>>>>>.
Aucune autre modification n'est apportée.