Concepto de cherry-pick: Copiar commits de una rama a otra

El comando git cherry-pick permite copiar commits específicos de una rama a otra sin que fusione todo el historial de cambios. Se usa mucho cuando se quiere aplicar modificaciones puntuales de una rama en otra distinta.

A veces, un commit hecho en una rama contiene mejoras o correcciones que se quieren integrar en otra rama sin arrastrar todos los cambios intermedios. En estos casos se usa el cherry-pick, porque permite seleccionar commits aislados y aplicarlos directamente.

Al realizar un cherry-pick, Git toma el commit especificado y reproduce sus cambios en la rama actual, creando un nuevo commit con los mismos contenidos pero con un identificador diferente. Esto asegura que el historial de ambas ramas permanezca separado, pero con los cambios que se quieren sincronizados.

Hay que tener cuidado al usar git cherry-pick porque si las ramas han divergido mucho, puede ser que surjan conflictos al aplicar los commits. Si esto ocurre, se tienen que resolver manualmente los conflictos .

El cherry-pick es muy útil en casos como:

• Hotfixes: Aplicar correcciones críticas de una rama de producción a la rama de desarrollo.
• Recuperación de cambios: Integrar commits específicos que se perdieron o se hicieron en la rama incorrecta.
• Colaboración selectiva: Compartir cambios concretos entre ramas de características sin fusionar ramas completas.

Uso básico: git cherry-pick <commit-hash>

El comando git cherry-pick se utiliza para aplicar un commit específico de otra rama en la rama actual. Su uso básico consiste en proporcionar el identificador SHA del commit que se quiera copiar.

Para aplicar un commit a la rama actual, se ejecuta el siguiente comando:

git cherry-pick <commit-hash>

Donde <commit-hash> es el identificador único del commit. Este hash se puede obtener utilizando git log en la rama donde reside el commit original.

Por ejemplo, si se quiere aplicar el commit con hash a1b2c3d4 de la rama feature a la rama actual, se seguirían estos pasos:

1. Cambiar a la rama destino si no se está en ella:

git checkout main

2. Ejecutar el cherry-pick del commit:

git cherry-pick a1b2c3d4

Este comando reproducirá los cambios del commit especificado en la rama actual e insertará un nuevo commit en el historial. El nuevo commit tendrá un identificador diferente, aunque el contenido sea el mismo.

Si se necesita aplicar una serie de commits consecutivos, se puede utilizar un rango de commits:

git cherry-pick inicio..fin

Donde inicio y fin son los hashes que delimitan el rango (sin incluir el commit inicio). Por ejemplo:

git cherry-pick a1b2c3d4..d4e5f6g7

Esto aplicará todos los commits desde a1b2c3d4 (sin incluirlo) hasta d4e5f6g7 (incluyéndolo) en la rama actual.

Además, si se desea aplicar múltiples commits no consecutivos, se pueden listar individualmente:

git cherry-pick a1b2c3d4 e5f6g7h8 i9j0k1l2

De esta manera, se aplicarán los commits con hashes a1b2c3d4, e5f6g7h8 e i9j0k1l2 en el orden especificado.

Resolución de conflictos: Al cherry-pickear cambios en conflicto

Cuando se hace un git cherry-pick, pueden surgir conflictos si los cambios del commit seleccionado entran en conflicto con los existentes en la rama actual. Estos conflictos ocurren cuando el mismo código ha sido modificado de manera diferente en ambas ramas.

Cuando se ejecuta git cherry-pick <commit-hash> y Git detecta un conflicto, el proceso se detiene y se muestra un mensaje indicando los archivos afectados. Para verificar el estado de los conflictos, se puede utilizar:

git status

Los archivos en conflicto aparecerán marcados como "both modified". Dentro de estos archivos, Git inserta marcadores de conflicto para resaltar las diferencias:

<<<<<<< HEAD
contenido de la rama actual
=======
contenido del commit cherry-pickeado
>>>>>>> a1b2c3d4

Se debe editar cada archivo en conflicto para resolver las diferencias y decidir qué cambios conservar, si los de la rama actual, los del commit cherry-pickeado o una combinación de ambos. Una vez resueltos los conflictos, se deben eliminar los marcadores (<<<<<<<, =======, >>>>>>>).

Después de resolver y guardar los archivos, se necesita añadir los cambios al área de preparación:

git add <archivo>

Para continuar con el cherry-pick después de resolver los conflictos, se ejecuta:

git cherry-pick --continue

Si se quiere abortar el proceso de cherry-pick y dejar la rama en su estado original, se puede utilizar:

git cherry-pick --abort

Se recomienda utilizar herramientas de fusión visual para facilitar la resolución de conflictos con editores como Visual Studio Code o IntelliJ IDEA, que ofrecen interfaces gráficas que simplifican este proceso y permiten comparar versiones lado a lado.

Al resolver conflictos, es importante:

• Revisar cuidadosamente cada cambio para evitar pérdidas de código.
• Mantener la coherencia del estilo y convenciones del proyecto.
• Probar el código después de finalizar la operación para detectar posibles errores introducidos durante la resolución.

Una vez completado el cherry-pick sin conflictos, el commit se integra en la rama actual con un nuevo identificador, preservando el contenido del commit original.

Casos de uso: Hotfixes, recuperación de commits específicos

El comando git cherry-pick se usa mucho cuando se necesitan aplicar cambios puntuales entre ramas sin fusionar todo el historial. Uno de los casos más comunes es la implementación de hotfixes en entornos de producción. Si se descubre un error en la rama principal y se corrige en una rama secundaria, se puede cherry-pickear ese commit a la rama de producción para solucionar el problema rápidamente.

Por ejemplo, si se trabaja en una rama develop y se encuentra un bug que también afecta a main, se realiza el commit con la corrección en develop:

git commit -m "Corrige error crítico en autenticación"

Luego, se cambia a la rama main y se aplica el cherry-pick del commit recién creado:

git checkout main
git cherry-pick <hash-del-commit>

De esta manera, se aplica el hotfix en producción sin importar otros cambios pendientes en develop.

También se usa para la recuperación de commits específicos que se han perdido o se necesitan en otra rama. Si un commit se realizó en la rama incorrecta o se requiere un cambio específico en varias ramas, se puede cherry-pickear ese commit a las ramas necesarias.

Por ejemplo, si accidentalmente se hizo un commit en la rama feature que debería estar en develop, se puede recuperar ese commit de la siguiente manera:

git checkout develop
git cherry-pick <hash-del-commit>

El git cherry-pick también facilita la colaboración en equipos donde diferentes desarrolladores trabajan en características separadas. Si una funcionalidad desarrollada por un miembro del equipo es necesaria en otra rama, se puede aplicar su commit específico sin esperar a que toda la rama sea fusionada.