Qué hace cherry-pick

git cherry-pick aplica el diff de uno o más commits sobre la rama actual como nuevos commits. Es la herramienta correcta cuando quieres un cambio específico sin hacer merge de toda la rama — típico para portar arreglos a una rama de release o para adelantar un hotfix.

Uso básico y por rangos

git cherry-pick <sha>
git cherry-pick A..B          # exclusivo de A, inclusivo de B
git cherry-pick A^..B         # inclusivo de A y B

Cherry-pick admite la misma sintaxis de rangos que git log. Usa --no-commit (-n) para preparar los cambios sin hacer commit — útil al aplicar varios picks como un único commit.

Resolver conflictos

Si un pick entra en conflicto, Git se detiene. Resuelve, prepara y continúa:

git cherry-pick --continue
git cherry-pick --skip
git cherry-pick --abort

Registrar la fuente

Usa -x para añadir una línea "(cherry picked from commit ...)" al mensaje, lo que les encanta a los auditores:

git cherry-pick -x <sha>

Mainline para merges

Hacer cherry-pick de un commit de merge es ambiguo: ¿qué padre proporciona la base? Usa -m:

git cherry-pick -m 1 <merge-sha>

El mainline 1 suele ser la rama que recibió el merge.

Trampa: historias divergentes

Cherry-pick crea un nuevo commit con un SHA diferente al original. Si ambas ramas eventualmente se fusionan, Git suele reconciliarlas, pero si las dos copias han divergido por ediciones posteriores, arriesgas re-aplicar o tener conflictos. Prefiere merge cuando se desea integración completa de rama.

Trampa: deriva semántica silenciosa

Un cherry-pick textualmente limpio aún puede romper el comportamiento si el código circundante ha cambiado de significado. Siempre ejecuta tests tras los picks, especialmente entre versiones distantes.

Rastreo de picks aplicados

Para encontrar qué commits en una rama fueron escogidos de otra parte, mira git log --grep="cherry picked from" cuando se usó -x. Para un enfoque más riguroso, ver git patch-id:

git log -p <sha> | git patch-id
git log -p main | git patch-id

Errores comunes

Hacer cherry-pick sin -x en una rama de release mantenida hace dolorosos los registros de auditoría. Olvidar -m en un commit de merge produce un pick vacío o un diff confuso. Cuando dudes, prefiere git rebase --onto para mover secuencias de commits entre ramas.