Cherry-pick — qué es, mecanismo y aplicación en Git

¿Qué es Cherry-pick?

Cherry-pick es un comando de Git que copia los cambios de un commit especificado y los aplica como un nuevo commit en la rama actual. El nombre proviene de la metáfora de "recoger cerezas": el desarrollador selecciona solo los commits que necesita, ignorando el resto.

A diferencia de Merge, cherry-pick no crea un commit de fusión ni requiere una fusión completa de ramas. A diferencia de Rebase, cherry-pick no transfiere una secuencia de commits — solo los especificados. Esto convierte a cherry-pick en una herramienta ideal para la transferencia selectiva de correcciones.

Según Atlassian, 2025, cherry-pick es utilizado por el 47% de los equipos que trabajan con múltiples ramas de lanzamiento simultáneamente. Cherry-pick es especialmente demandado en el desarrollo móvil, donde se mantienen varias versiones de una aplicación (versiones LTS) y es necesario transferir correcciones entre ellas.

Mecanismo de transferencia

Al ejecutar cherry-pick, Git calcula el diff entre el commit especificado y su padre, luego aplica este diff a la rama actual. Si los cambios se aplican sin conflictos — Git crea un nuevo commit con el mismo mensaje pero un nuevo SHA. Si hay conflicto — cherry-pick se detiene para resolución manual.

Cómo funciona Cherry-pick

La sintaxis de cherry-pick es simple: indique el hash del commit que desea transferir. Git copia los cambios a la rama actual como un nuevo commit. Se admite la transferencia de varios commits a la vez y de rangos completos.

# Transferir un commit individual a la rama actual
git cherry-pick a1b2c3d4

# Transferir varios commits
git cherry-pick a1b2c3d4 e5f6g7h8

# Transferir un rango de commits (de a1b2 a f9e8, excluyendo a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Después de ejecutar cherry-pick, la rama actual recibe un nuevo commit con los cambios del origen. El mensaje del commit se copia del original por defecto, pero puede modificarse con la bandera -n (no crear commit) o --edit (editar mensaje).

Ejemplo de transferencia de una corrección

Consideremos un escenario típico: se encuentra y corrige un error crítico en develop, que también está presente en la rama de lanzamiento release/v2.0. Solo es necesario transferir esta corrección, sin fusionar todo develop en la rama de lanzamiento.

# Encontrar el hash del commit con la corrección en develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Cambiar a la rama de lanzamiento
git checkout release/v2.0

# Aplicar la corrección
git cherry-pick a1b2c3d4

# Si hay conflicto — resolver y continuar
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

La bandera -x añade una referencia al SHA original en el mensaje del commit: "(cherry picked from commit a1b2c3d4)". Esto facilita el seguimiento de dónde se transfirió el commit. Se recomienda usar -x en todos los escenarios excepto borradores temporales.

Trabajo con conflictos

En caso de conflicto, cherry-pick se comporta como merge: Git se detiene y marca los archivos en conflicto. El desarrollador resuelve el conflicto, ejecuta git add y luego git cherry-pick --continue. Para cancelar — git cherry-pick --abort. La bandera --strategy permite especificar una estrategia de fusión (por ejemplo, recursive con opciones).

# Resolución de un conflicto durante cherry-pick
# Git muestra los archivos en conflicto
git status

# Resolver manualmente, luego:
git add archivo_permitido.kt
git cherry-pick --continue

# O cancelar cherry-pick:
git cherry-pick --abort

Cuándo usar Cherry-pick

Cherry-pick es óptimo en escenarios donde se requiere una transferencia selectiva de cambios sin fusionar ramas enteras. Veamos cinco casos principales en los que cherry-pick se convierte en la mejor opción.

• Transferencia de hotfix — se encuentra una corrección en develop, pero debe aplicarse a la rama de lanzamiento (release/v2.0). Cherry-pick transfiere solo el commit de la corrección sin afectar las funciones no terminadas de develop
• Backport a versiones anteriores — una corrección para la versión actual debe transferirse a un lanzamiento LTS. En lugar de fusionar toda la base de código actual, cherry-pick selecciona solo los commits necesarios
• Deshacer un commit en la rama incorrecta — si un commit se hizo en la rama equivocada, cherry-pick lo transfiere a la correcta y el commit original se revierte
• Transferencia de documentación — los cambios en README o archivos de configuración que deben estar en todas las ramas son convenientes de transferir mediante cherry-pick
• Aplicación selectiva — de una rama prototipo, solo se necesita tomar un commit exitoso sin transferir todo el prototipo al desarrollo principal

Para el desarrollo móvil, cherry-pick es críticamente importante al mantener varias versiones de una aplicación. Por ejemplo, si se encuentra un error en la versión 3.2 ya publicada en Google Play, y develop contiene código para la versión 4.0 — cherry-pick permite transferir la corrección a la rama v3.x sin fusionar todos los cambios disruptivos. Esto es especialmente relevante para proyectos donde se mantienen simultáneamente dos o más versiones principales con diferentes API y dependencias.

Ejemplo práctico: en una aplicación móvil se detecta un crash durante la autenticación con Google Sign-In en Android 12. La corrección se realiza en develop y pasa la revisión de código. Sin embargo, la rama de lanzamiento actual v2.5 ya está en fase de beta testing. Cherry-pick del commit de corrección desde develop a release/v2.5 permite incluir la corrección en el próximo lanzamiento sin transferir otros cambios que aún no están listos para publicación.

Al usar cherry-pick en proyectos móviles, es importante considerar las dependencias: si la corrección afecta archivos que fueron modificados en develop después del punto de divergencia de la rama de lanzamiento, cherry-pick puede traer un conjunto incompleto de cambios. En tales casos, es necesario verificar que todos los cambios relacionados también se hayan transferido, de lo contrario la aplicación podría no compilarse o funcionar incorrectamente. Siempre verifique la compilación después de cherry-pick antes de enviar los cambios a la rama compartida.

Cherry-pick vs Merge vs Rebase

Las tres herramientas principales de integración de cambios en Git — merge, rebase y cherry-pick — resuelven diferentes tareas. La elección depende de cuánto cambio necesita transferirse y cómo debe verse el historial.

Merge — cuando necesita fusionar dos ramas por completo y conservar la información de bifurcación. Rebase — cuando necesita actualizar una rama personal al estado más reciente con un historial limpio. Cherry-pick — cuando solo necesita un commit o varios commits seleccionados.

En la práctica, estas herramientas se combinan: una funcionalidad se desarrolla con rebase periódico sobre develop, luego se fusiona mediante --no-ff merge, y cuando es necesario transferir una corrección a otra rama, se usa cherry-pick. Cada herramienta resuelve su propia tarea en su propia etapa.

Riesgos y limitaciones de Cherry-pick

Cherry-pick es una herramienta útil pero potencialmente peligrosa cuando se usa incorrectamente o en exceso. Los principales riesgos están relacionados con la duplicación de commits, la pérdida de contexto y los conflictos durante fusiones posteriores.

• Duplicación de commits — si el mismo commit entra más tarde en la rama mediante merge, Git creará un segundo commit idéntico en cambios. Esto contamina el historial y dificulta git bisect
• Pérdida de contexto — cherry-pick transfiere el diff pero no transfiere información sobre commits padres ni dependencias. Si cherry-pick aplicó el commit A sin el commit B del que A dependía, pueden ocurrir errores lógicos
• Conflictos en merge — después de cherry-pick, durante una fusión completa de ramas, Git puede ver los mismos cambios dos veces y crear conflictos que podrían haberse evitado con un merge normal
• Falta de trazabilidad — sin la bandera -x, es imposible saber que un commit fue transferido desde otra rama. Al buscar el origen de un cambio, un desarrollador puede pasar horas averiguando de dónde vino el commit

Recomendaciones para minimizar riesgos: use siempre la bandera -x para indicar el SHA original, documente la razón del cherry-pick en el mensaje del commit, y cuando sea posible, use merge en lugar de cherry-pick cuando el contexto lo permita. Si los cherry-picks se vuelven numerosos — considere reestructurar las ramas.

Verificaciones automatizadas para Cherry-pick

Los pipelines de CI deben considerar cherry-pick como un escenario separado. Se recomienda configurar una verificación automatizada: cuando se crea un commit cherry-pick, CI verifica que los archivos modificados coincidan con el conjunto esperado y ejecuta pruebas para los módulos afectados. Esto reduce el riesgo de regresión al transferir cambios entre ramas.