2011-02-09 11 views
5

Para mover un individuo de una rama a otra me doy cuenta de que hay algunas opciones en git. He experimentado con git merge y git cherry-pick, pero no veo cuando es preferible git cherry-pick.¿En qué caso se necesitaría git cherry-pick en lugar de git merge?

Mi opinión es la siguiente:

git merge <hash> mueve la confirmación especificada de una rama a la otra preservarla como una confirmación.

git cherry-pick <hash> crea una copia de la confirmación en la segunda rama, pero está separada con su propio hash de confirmación.

La primera opción me parece preferible, pero ¿cuáles son las instancias en que se preferiría cherry-pick?

Respuesta

7

Supongamos que tiene una sucursal desde master que tiene muchos compromisos. Tal vez hizo un cambio que es apropiado en master, pero no desea traer todos los de los cambios (una pequeña corrección de error, por ejemplo, o la adición de una característica pequeña). Con git cherry-pick, puede tomar solo que confirma desde la otra rama y lo lleva al master.

+0

si fusiona * especificando * el hash, ¿solo fusiona ese compromiso? – hvgotcodes

+3

@hvgotcodes: No, cuando te fusionas, obtienes '' y todos los antepasados ​​en '' porque divergía de la rama en la que te estás fusionando. Un nombre de sucursal es realmente solo un nombre hash. – mipadi

+0

gracias por aclarar eso - +1. – hvgotcodes

0

Otro caso de uso es cuando pierde un compromiso y desea recuperarlo. http://www.programblings.com/2008/06/07/the-illustrated-guide-to-recovering-lost-commits-with-git/

Mathieu recuperación @ ml (maestro) $ git cherry-pick 93b0c51cfea8c731aa385109b8e99d19b38a55be Acabado de un cereza-escoge. Creado cometer f443703: Ahora que era fresco 1 archivos cambiados, 1 inserciones (+), 0 eliminaciones (-) el modo de crear 100.644 cool_file

Es necesario tener el hash, por supuesto.