Git – Pico de cereza

Seleccionar cereza en git significa elegir una confirmación de una rama y aplicarla a otra rama. Esto contrasta con otras formas, como fusionar y reorganizar, que normalmente aplican muchas confirmaciones en otra rama.

La selección de cerezas es como cambiar la base , un concepto avanzado y también un comando poderoso. Se usa principalmente si no desea fusionar toda la rama y desea algunas de las confirmaciones.

Implementación: 

Supongamos que un desarrollador no reconoce en qué rama se encuentra actualmente y, por error, se compromete con otra rama en lugar de comprometerse con la rama principal. Ahora, para solucionarlo, primero tiene que ejecutar git show, luego guardar la confirmación, luego verificar la rama principal, aplicar el parche allí y confirmar con el mismo mensaje de confirmación. Pero todo esto se puede hacer automáticamente usando solo un comando, es decir , selección de cereza.

Para entender mejor, consulte el siguiente diagrama de la siguiente manera: 

El comando para Cherry-pick es el siguiente: 

git cherry-pick<commit-hash>

Hash de confirmación: un hash de confirmación es un identificador único generado por Git. Cada confirmación tiene su único hash de confirmación.

Nota: Mientras usa este comando, asegúrese de estar en la rama en la que desea aplicar la confirmación.

Algunos casos de uso importantes de Cherry-pick son los siguientes: 

1. Si, por error, realiza una confirmación en una rama incorrecta, puede aplicar los cambios necesarios utilizando la función de selección automática.
2. Supongamos que la misma estructura de datos debe ser utilizada tanto por el frontend como por el backend de un proyecto. Luego, un desarrollador puede usar cherry-pick para seleccionar la confirmación y usarla en su parte del proyecto.
3. En el momento en que se encuentra un error, es fundamental enviar una solución a los clientes finales tan pronto como sea posible.
4. Algunas veces, una rama de componente puede volverse obsoleta y no converger en la rama principal y la solicitud puede cerrarse, pero dado que git nunca pierde esas confirmaciones, puede seleccionarse y volver.

Desventajas de usar Cherry Pick

La selección de cerezas no debe usarse siempre, ya que puede causar compromisos de copia y numerosas situaciones en las que la selección de cerezas funcionaría, las fusiones convencionales son del agrado de todas las cosas consideradas. Además, en la situación en la que las confirmaciones de 2 o más sucursales actualizan líneas de código similares con varias sustancias y seleccionan una confirmación para la otra sucursal, también genera conflicto.

¿Cómo usar cherry-pick?

Aquí está la explicación paso a paso del uso del comando cherry-pick en el proyecto creado a continuación que se muestra a continuación de la siguiente manera: 

Paso 1:   Abriendo git bash y creando un nuevo proyecto llamado muestra e inicializando el repositorio usando el comando git init .

Paso 2: crear un archivo ‘.txt’ usando el comando vi para el proyecto, digamos un archivo de índice y agréguelo a nuestro proyecto de muestra y haga una confirmación y escriba un mensaje de confirmación antes de presionar Enter.

Nota: Después de ejecutar el comando vi <file_name> , escriba :wq para guardar y salir del archivo. 

Uno puede verificar su compromiso con el comando git log fácilmente:

Paso 3: Ahora suponga que tenemos 2 versiones, así que cree 2 ramas diferentes usando el comando git branch y muévase a una rama, digamos 2 usando el comando git checkout .

Nota: Uno puede ver todas las ramas simplemente ejecutando el comando git branch como se muestra en el siguiente diagrama.

Paso 4: ahora suponga que desea trabajar en alguna función nueva, por lo que crear y agregar un nuevo archivo de función digamos feature.txt usando vi y agregar comando respectivamente como se muestra a continuación. Luego confirme sus cambios con un mensaje de confirmación.

Uno puede verificar su compromiso con el comando git log como se muestra a continuación:

Paso 5:  ahora supongamos que encontramos un error en nuestra función y nos enteramos de que este mismo error también está presente en nuestra rama 1. 

Y ahora estamos tratando de corregir algún error o problema como se muestra a continuación agregando un archivo fix.txt, supongamos, y agréguelo a la rama actual, es decir, 2 y confirme los cambios necesarios.

Comprobando nuestros compromisos finales:

Paso 6: ahora, hemos corregido el error en la rama 2, pero también debemos agregar esta solución a nuestra rama 1, pero no queremos fusionar esta rama 2 en nuestra rama 1, porque el trabajo aún podría ser yendo a la función. 

Por lo tanto, en este escenario, podemos seleccionar este compromiso en particular. Para hacerlo, simplemente copie el valor hash resaltado en el diagrama anterior, luego muévase a la rama 1 usando el pago y luego use el comando cherry-pick y pegue el hash que acabamos de copiar.

Como se ve claramente en lo anterior, notamos que anteriormente solo teníamos index.txt antes de hacer una selección selectiva, pero ahora tenemos el archivo fix.txt también en nuestra primera rama.

Ahora, si intentamos verificar git log –oneline , podremos ver que el compromiso también vino en la rama 1.