Cherry-pick: qué es, cómo se realiza y comandos Git

Qué es cherry-pick en Git

Cherry-pick es el comando git cherry-pick que toma los cambios de un commit existente y los aplica como un nuevo commit en la rama actual. El commit original permanece en su lugar en su propia rama, mientras que se crea una copia de los cambios en la rama de destino. El comando es útil cuando se necesita transferir una corrección específica sin mover toda una rama.

Sintaxis: git cherry-pick <commit-hash>. Git analiza la diferencia (diff) del commit especificado con respecto a su padre y aplica esa diferencia a la rama actual. Si se modifican varios archivos, todos se transfieren juntos. El comando también acepta rangos: git cherry-pick A..B — todos los commits de A a B, excluyendo A.

Las banderas amplían sus capacidades: -n (--no-commit) aplica los cambios al directorio de trabajo y al índice sin crear un commit — útil cuando se necesita combinar cambios de varios commits en uno solo. La bandera -x agrega una línea (cherry picked from commit ...) al mensaje del commit, lo que facilita el seguimiento del origen de los cambios en el historial.

# Cherry-pick de un solo commit por hash
git cherry-pick a1b2c3d

# Cherry-pick de múltiples commits (secuencialmente)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick sin auto-commit
git cherry-pick -n a1b2c3d

# La bandera -x agrega referencia al commit original
git cherry-pick -x a1b2c3d

Cuándo usar cherry-pick

El escenario principal es transferir correcciones entre ramas de lanzamiento. Imagine: se encontró y corrigió un error crítico en develop. La rama de lanzamiento release/v2.1 ya está separada y también contiene este error. Fusionar todo develop en release traería mucho código no terminado, mientras que aplicar cherry-pick al commit de la corrección es una solución segura y precisa.

El segundo escenario es revertir cambios con restauración posterior. Si un commit fue revertido mediante git revert y luego resulta que la reversión fue un error — aplicar cherry-pick al commit revertido restaura los cambios. Esto es más correcto que revertir una reversión porque no crea conflictos repetidos.

El tercer escenario es combinar commits de diferentes ramas de funcionalidad en una rama de prueba para pruebas de integración. En lugar de fusionar varias ramas sin terminar (con código incompleto), se pueden seleccionar solo los commits listos de cada una y probar cómo funcionan juntos.

• Correcciones de errores — transferir una corrección de develop a release sin código no terminado.
• Hotfix — aplicar una corrección de una rama hotfix a main y develop simultáneamente.
• Deshacer una reversión errónea — aplicar cherry-pick al commit revertido para restaurar los cambios.
• Pruebas — recopilar commits seleccionados de diferentes ramas para pruebas de integración.

Cherry-pick vs rebase y merge

Cherry-pick se diferencia de rebase y merge en que trabaja a nivel de commits individuales en lugar de ramas enteras. Mientras que rebase transfiere todos los commits de una rama y merge combina dos ramas, cherry-pick selecciona solo los necesarios. Esto lo convierte en una herramienta más precisa, pero también más manual.

Otra diferencia es la autoría. Durante cherry-pick, Git por defecto conserva el autor del commit original, pero el committer pasa a ser el usuario actual. El mensaje del commit puede rastrear el origen mediante la bandera -x. Durante rebase, tanto el autor como el committer pasan a ser el usuario actual con un nuevo hash.

Rendimiento: aplicar cherry-pick a un solo commit es más rápido que fusionar dos ramas con muchos commits. Pero si se necesitan transferir docenas de commits, es mejor crear una rama temporal y realizar un rebase — será más eficiente y no requerirá especificar docenas de hashes.

Transferir múltiples commits

Múltiples commits se pueden transferir con un solo comando listando sus hashes separados por espacios: git cherry-pick A B C. Git aplica los commits secuencialmente en el orden especificado. Si algún commit causa un conflicto, cherry-pick se pausa, y el desarrollador debe resolver el conflicto y luego continuar con git cherry-pick --continue.

Rango de commits: git cherry-pick A..B (todos los commits después de A hasta B, excluyendo A) y git cherry-pick A^..B (todos los commits desde A inclusive hasta B). Los rangos son convenientes cuando se necesita transferir todos los commits de una rama sin la relación padre — por ejemplo, al mover una funcionalidad completa de una rama antigua a una nueva.

La bandera --strategy determina cómo Git aplica los cambios. Por defecto se usa la estrategia recursive, pero se puede especificar ours o theirs para seleccionar automáticamente un lado del conflicto. La bandera --mainline se usa al aplicar cherry-pick a un commit de fusión — especifica el número de padre (1 o 2) contra el cual se calcula el diff.

# Rango de commits cherry-pick
git cherry-pick develop~5..develop~2

# Cherry-pick de commit de fusión (especificar padre)
git cherry-pick -m 1 m9n0o1p

# Usar estrategia theirs
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Continuar después de resolver conflictos
git cherry-pick --continue

Conflictos durante cherry-pick

Los conflictos durante cherry-pick ocurren cuando los cambios del commit transferido afectan las mismas líneas que fueron modificadas en la rama de destino. Git pausa la ejecución, marca los archivos en conflicto y espera la resolución. En el estado, estos archivos se muestran como both modified.

Pasos para resolver un conflicto: abrir el archivo en conflicto, encontrar los marcadores de conflicto (<<<<<<<, =======, >>>>>>>), editar el contenido, eliminar los marcadores, ejecutar git add para los archivos resueltos y ejecutar git cherry-pick --continue. Si el conflicto no se puede resolver — git cherry-pick --abort cancela todo el cherry-pick, devolviendo la rama a su estado original.

Un problema común: el commit ya contiene cambios equivalentes a los existentes. En este caso, Git informa “nothing to commit” o “empty commit” al intentar cherry-pick. Las banderas --keep-redundant-commits y --empty=keep obligan a Git a crear un commit vacío para preservar la secuencia, mientras que --skip permite omitir dicho commit.

# Conflicto durante cherry-pick — detener
git cherry-pick a1b2c3d
# error: no se pudo aplicar a1b2c3d... mensaje del commit

# Resolver conflicto → agregar al índice
git add src/conflicted_file.swift
git cherry-pick --continue

# Omitir commit vacío (ya aplicado)
git cherry-pick --skip

# Anulación completa
git cherry-pick --abort

Mejores prácticas de cherry-pick

Primera regla: verifique siempre que el commit que se transfiere sea autónomo. Si el commit A depende de cambios en el commit B que no se transfiere, aplicar cherry-pick a A puede romper la compilación. Antes de aplicar cherry-pick, es útil verificar qué archivos modificó el commit mediante git show --stat <hash>.

Segunda regla: documente las operaciones de cherry-pick. Use la bandera -x para que el mensaje del commit conserve una referencia al commit original. Esto ayudará durante el análisis posterior del historial a entender de dónde provino el cambio. Sin -x, un cherry-pick parece un commit normal, y su origen solo se puede determinar mediante git log --graph.

Tercera regla: evite cherry-pick entre ramas que han divergido demasiado. Si ha pasado mucho tiempo desde que se creó el commit y la base de código ha cambiado significativamente, los conflictos serán numerosos y complejos. En tales casos, es mejor reimplementar la corrección en la rama de destino — llevará menos tiempo que resolver docenas de conflictos.

• Cherry-pick solo commits autónomos sin dependencias externas.
• La bandera -x es obligatoria para documentar el origen del commit en el mensaje.
• Evite aplicar cherry-pick a commits antiguos con gran divergencia en la base de código.
• CI/CD verifique la compilación después de cherry-pick: es posible que no haya ocurrido un conflicto, pero el código puede no compilar.
• Comentario en PR al crear un pull request, indique qué commits fueron transferidos mediante cherry-pick.