git pic à cerises dans git signifie choisir un commit dans une branche et l'appliquer à une autre branche. Cela contraste avec d'autres moyens tels que fusionner et dépassement qui appliquent normalement de nombreux commits dans une autre branche.

git Cherry-pick est comme rebasage , un concept avancé et aussi une commande puissante. Il est principalement utilisé si vous ne souhaitez pas fusionner toute la branche et que vous souhaitez certains commits.

Quand utiliser le Cherry Pick ?

Supposons qu'un développeur ne parvienne pas à reconnaître sur quelle branche il se trouve actuellement et que, par erreur, il s'engage sur une autre branche au lieu de s'engager sur la branche principale. Maintenant, pour résoudre ce problème, il doit d'abord courir spectacle git , puis enregistrez le commit, consultez la branche principale, appliquez-y un correctif et validez avec le même message de commit. Mais tout cela peut être fait automatiquement en utilisant une seule commande, c'est-à-dire pic à cerises.

variable globale js

Afin de mieux comprendre, reportez-vous au schéma ci-dessous comme suit :

Avant la cueillette des cerises

Après la cueillette des cerises

La commande pour Cherry-pick est la suivante :

git cherry-pick>

Valider le hachage : Un hachage de validation est un identifiant unique généré par Git . Chaque commit a son seul hachage de commit.

Note: Lorsque vous utilisez cette commande, assurez-vous que vous êtes sur la branche sur laquelle vous souhaitez appliquer la validation.

Comment utiliser une sélection de cerises ?

Voici l'explication étape par étape de l'utilisation de la commande Cherry-pick dans le projet créé ci-dessous, étape par étape, comme suit :

Étape 1: Ouverture du git bash et créer un nouveau projet nommé échantillon et initialiser le dépôt à l'aide du c'est chaud commande.

Étape 2: Créer un ' .SMS' fichier utilisant nous commande au projet, disons un fichier d'index et ajoutons-le à notre exemple de projet, effectuons une validation et écrivons un message de validation avant d'appuyer sur Entrée.

Note: Après avoir exécuté le nous commande, tapez :wq pour enregistrer et quitter le fichier.

barre d'outils d'accès rapide aux mots

On peut vérifier votre commit en journal git commandez facilement :

Étape 3: Supposons maintenant que nous ayons 2 versions, créez donc 2 branches différentes en utilisant le branche git commande et passez à une branche, disons 2 en utilisant git paiement commande.

Note: On peut simplement visualiser toutes les branches en exécutant la commande git branch comme indiqué dans le diagramme ci-dessous.

Étape 4: Supposons maintenant que vous souhaitiez travailler sur une nouvelle fonctionnalité, donc créer et ajouter un nouveau fichier de fonctionnalité, disons feature.txt en utilisant nous et ajouter commande respectivement comme indiqué ci-dessous. Validez ensuite vos modifications avec un message de validation.

On peut vérifier votre commit par la commande git log comme indiqué ci-dessous :

Cela montre clairement notre premier commit où se trouve notre branche 1 et dans la branche 2, elle s'est éloignée plus loin et nous travaillons actuellement sur notre fonctionnalité dans la branche 2.

Étape 5 : Supposons maintenant que nous ayons trouvé un bug dans notre fonctionnalité et que nous apprenions que ce même bug est également présent dans notre branche 1.

Et maintenant, nous essayons de corriger un bug ou un problème comme indiqué ci-dessous en ajoutant un fichier fix.txt, supposons-le, et en l'ajoutant à la branche actuelle, c'est-à-dire 2, et en validant les modifications requises.

Vérification de nos commits finaux :

Étape 6 : Maintenant, nous avons corrigé le bug dans la branche 2, mais nous devons également ajouter ce correctif à notre branche 1, mais nous ne voulons pas fusionner cette branche 2 dans notre branche 1, car le travail est peut-être encore en cours sur la fonctionnalité.

Ainsi, dans ce scénario, nous pouvons sélectionner ce commit particulier. Pour ce faire, copiez simplement le hacher valeur mis en évidence dans le diagramme ci-dessus, puis passez à la branche 1 en utilisant checkout , puis utilisez la commande pic à cerises et collez le hachage que nous venons de copier.

Comme le montre clairement ce qui précède, nous remarquons qu'auparavant nous n'avions que index.txt avant de procéder à la sélection, mais maintenant nous avons également le fichier fix.txt dans notre 1ère branche.

renommer un répertoire Linux

Maintenant, si nous essayons de vérifier journal git –oneline , nous pourrons voir que le commit est également arrivé dans la branche 1.

Quelques cas d'utilisation importants de Cherry-pick

Voici quelques applications courantes de Cherry-Pick :

1. Si, par erreur, vous effectuez un commit dans une branche incorrecte, alors en utilisant la sélection sélective, vous pouvez appliquer les modifications requises.
   
2. Supposons que la même structure de données doive être utilisée à la fois par le frontend et le backend d'un projet. Ensuite, un développeur peut utiliser Cherry-pick pour sélectionner le commit et l'utiliser pour sa partie du projet.
   
3. Au moment où un bug est détecté, il est essentiel de transmettre un correctif aux clients finaux aussi rapidement que possible.
   
4. Parfois, une branche de composant peut vieillir et ne pas converger vers la branche principale et la requête peut être fermée, mais comme git ne perd jamais ces validations, elle peut être sélectionnée et elle reviendra.

Inconvénients de l’utilisation de Cherry Pick

Le Cherry-picking ne doit pas toujours être utilisé car il peut provoquer des validations de copie et de nombreuses situations dans lesquelles le Cherry-picking fonctionnerait, les fusions conventionnelles sont appréciées tout bien considéré. De plus, dans la situation où les commits de 2 branches ou plus mettent à jour des lignes de code similaires avec diverses substances et que git sélectionne un commit dans l'autre branche, cela provoque également un conflit.

Conclusion

La commande Cherry-pick de Git est un outil puissant pour appliquer de manière sélective des commits spécifiques entre les branches. C’est idéal pour corriger les erreurs et partager du code, mais en abuser peut entraîner des problèmes, en particulier lorsque les commits touchent les mêmes lignes de code. Alors, utilisez-le à bon escient pour maintenir un historique de code propre et efficace.