- Básicos Git (I): Cherry pick
- Básicos Git (II): Rebase
- Básicos Git (III): Revert
- Básicos Git (IV): Reset
- Básicos Git (V): Amend
- Básicos Git (VI): Stash
El uso básico de Git es bastante conocido sin embargo hay algunos conceptos que se suelen nombrar y quizás a veces inducen al error, en este caso comentaré los más habituales que se suelen ver en el plugin de VS2017 para Git.
Para este ejemplo se ha creado una rama master y una rama develop que hereda de master. En el historial de Git del plugin de VisualStudio se vería de la siguiente forma.

Aquí podemos ver que nos está indicando con la marca roja master que master ha tenido commits hasta el commit id 9e3acdb5, con la marca roja develop vemos que esta rama está avanzada y tiene más commits que master.
Para este ejemplo solo hemos añadido un fichero en master y después en la rama develop hemos continuado haciendo modificaciones sobre este fichero.
Cuando fusionemos las ramas las dos estarán sincronizadas por lo que veremos algo como esto, las dos marcas rojas alineadas.

Cherry pick
El concepto de cherry pick es poder coger uno o varios commits de una rama y copiarlos a otra rama distinta, este concepto lo vamos a aplicar a la fusión (merge) de ramas.
La idea de un merge es fusionar dos ramas entre sí, la forma más habitual es fusionar en una rama destino (en este caso master con los commits en blanco) una rama origen (develop con los commits en azul) incluyendo en la rama destino tantos commits y en el mismo orden como commits tiene la rama origen. (Figura 1).
Existe otra opción que consiste en fusionar todos los cambios de una rama origen en una rama destino en un solo commit, es decir todos los commits de la rama origen se agrupan en uno solo y es este el que se inserta en la rama destino. (Figura 2).

El comando merge por defecto no hace un cherry pick, el plugin de VisualStudio permite hacerlo de dos formas diferentes, en ambos casos el comentario que se verá en la rama destino será el del último commit.
Cherry pick de una rama
En el caso de una rama entera habría que posicionarse en la rama origen de los commits y después hacer click en la opción cherry pick en la rama que va a recibir los commits.
En este ejemplo la rama develop va a recibir todos los commits de master.

Esta acción genera un conflicto al contrario que un merge normal, esto se debe a que cherry pick solo transfiere commits no es un merge en el sentido estricto, los errores de conflicto se solucionan de la forma habitual.
Cherry pick de commits individuales
Otra opción es seleccionar específicamente uno o varios commits y transferirlos a otra rama, en este caso nos situamos en la rama destino y abrimos el historial de la rama origen, seleccionamos los commits que nos interesen y hacemos click en cherry pick.
En este caso solo habrá conflictos si seleccionamos varios commits o elegimos uno que no sea inmediatamente posterior tanto en la rama origen como destino, es decir que si hicieramos cherry pick de cada commit en el mismo orden en la rama destino no deberíamos tener conflictos, realmente esta última forma es lo mismo que emular un merge normal.
