Rebase y rebase interactivo trabajan con el conjunto de commits de una rama: los descomponen, los reordenan, los reaplican. git cherry-pick hace algo mucho más quirúrgico: coge un commit concreto, esté donde esté, y aplica su cambio sobre la rama en la que estás ahora, creando un commit nuevo.

El nombre lo dice todo: cherry-picking es escoger las cerezas una a una. Y como toda herramienta quirúrgica, es excelente en manos que saben cuándo usarla y peligrosa en manos que la usan por costumbre. Un cherry-pick mal puesto duplica trabajo, confunde el historial y provoca conflictos absurdos meses después.

Ana lo necesita hoy. Ha corregido en main el fallo de que el foco se pierde al borrar una tarea, y la versión 1.x que sigue desplegada en el cliente tiene el mismo fallo pero vive en una rama de mantenimiento aparte, que no puede recibir todo lo que hay en main. Quiere ese commit y nada más.

1. Qué hace git cherry-pick
2. El caso de Ana: llevar una corrección a mantenimiento
3. Varios commits y rangos
4. Opciones útiles: -n, -x, -e, -s
5. Conflictos al hacer cherry-pick
6. Rescatar un commit de una rama abandonada
7. El problema de los duplicados
8. Detectar duplicados: git cherry y --cherry-mark
9. Cuándo NO usar cherry-pick

Git toma el diff que introduce <sha> (es decir, la diferencia entre ese commit y su padre), lo aplica sobre el estado actual de tu rama y crea un commit nuevo con ese cambio.

La palabra clave, otra vez, es nuevo. Igual que en el rebase (lección 05-01), y por el mismo motivo del modelo de datos de la lección 01-04: el commit resultante tiene otro padre, luego otro contenido, luego otro hash. No es "el mismo commit en dos ramas": son dos commits distintos que casualmente introducen el mismo cambio.

El diagrama miente un poco a propósito, porque gitGraph reutiliza la etiqueta del commit original. En realidad, en mantenimiento/1.x aparece un commit distinto, con hash b9e2c17, que introduce el mismo cambio que 7d3a8f4. Recuérdalo cada vez que veas un diagrama de cherry-pick: la flecha punteada significa "el mismo cambio", nunca "el mismo objeto".

Qué se conserva y qué no, para completar la tabla mental que empezaste en 05-01:

Que se conserve la autoría es importante: cuando llevas la corrección de un compañero a otra rama, el crédito sigue siendo suyo.

El repositorio de gestor-tareas tiene dos líneas vivas:

• main, donde se desarrolla la versión 2.
• mantenimiento/1.x, que reproduce lo que está desplegado en el cliente y solo recibe correcciones.

Ana corrigió el fallo del foco en main:

El commit es pequeño y autocontenido, que es exactamente lo que hace a un commit buen candidato para cherry-pick:

Ahora, el trasplante:

Hash nuevo (b9e2c17), autoría de Ana intacta, cambio idéntico, y una línea al final del mensaje que dice de dónde vino. Esa línea la ha puesto -x, y merece su apartado.

git cherry-pick acepta varios commits sueltos y rangos.

Se aplican en el orden en que los escribes, no en orden cronológico. Si dependen unos de otros, escríbelos en el orden en que se hicieron o tendrás conflictos evitables.

Los rangos usan la misma notación de dos puntos de la lección 02-06, y con la misma trampa:

Ejemplo con nombres reales: Bruno quiere llevar a mantenimiento los tres commits de correcciones que hizo en funcionalidad/exportacion-csv, que van de 6e1d9f3 a 9c7e5a1:

Tres commits nuevos con tres hashes nuevos, en el orden correcto.

Un aviso importante: un rango de cherry-pick no incluye los commits de fusión. Si el rango contiene una fusión, Git la salta silenciosamente (o falla, según el caso). Trasplantar un commit de fusión requiere -m para elegir el padre respecto al cual calcular el diff, igual que en revert (lección 05-06), y casi nunca es lo que quieres. Si tu rango tiene fusiones, probablemente lo que buscabas era un merge o un rebase.

-n (--no-commit) sirve para agrupar. Si quieres que cinco commits pequeños lleguen a la rama de destino como uno solo:

Los tres cambios quedan preparados en el índice y tú decides cuándo y con qué mensaje confirmarlos. Si te arrepientes a mitad, git cherry-pick --abort deshace todo lo acumulado.

-x es fundamental en ramas de mantenimiento y es la razón por la que existe la opción. Deja una nota en el mensaje que permite, meses después, contestar a la pregunta "¿de dónde salió este commit?":

Con esa línea, git show 7d3a8f4 te lleva al original y puedes ver su contexto completo. Sin ella, el commit aparece en la rama de mantenimiento sin explicación posible.

Cuidado con un matiz: -x solo tiene sentido cuando el commit de origen es público. Si copias un commit de una rama local que vas a borrar, la referencia apuntará a un hash que nadie más puede resolver, y la nota confunde más que ayuda. La documentación de Git es explícita en esto: úsalo para copiar de una rama pública a otra.

-s añade la línea Signed-off-by:, una convención de proyectos que exigen certificar el origen de las aportaciones (el Developer Certificate of Origin del núcleo de Linux es el caso canónico). No es una firma criptográfica; eso son las etiquetas y commits firmados con GPG, que se ven en la lección 08-05.

Un cherry-pick aplica un parche sobre un contexto que puede haber cambiado. Es muy normal que conflictúe, sobre todo cuando la rama de destino ha divergido mucho.

La mecánica de resolución —marcadores, git status, editar, git add— es la de la lección 03-05 y no cambia. Lo específico es cómo se sale:

Y aquí, buena noticia: en un cherry-pick, ours y theirs NO están invertidos. ours es tu rama de destino (donde estás) y theirs es el commit que estás trayendo, que es lo intuitivo. La inversión de la lección 05-01 es una peculiaridad del rebase, no una regla general.

Si el conflicto te parece muy grande para el tamaño del cambio, es una señal: probablemente estés portando un commit que depende de otro que no has portado. Mira git log --oneline <origen> alrededor del commit y comprueba si hay un commit previo que también hace falta.

Cuando el commit conflictúa porque su cambio ya está aplicado en la rama de destino, Git te lo dice de otra forma:

Ahí, git cherry-pick --skip es la respuesta correcta: no hay nada que aportar.

El segundo caso legítimo. Carla empezó funcionalidad/etiquetas-color y el equipo decidió aparcarla: el enfoque no convencía. Pero dentro había un commit que sí valía: una función que valida el formato hexadecimal de un color y que resulta útil para otra cosa.

Aquí Carla no ha usado -x, y hace bien: la rama de origen se va a borrar, así que dejar en el mensaje una referencia a un hash que quedará huérfano no ayuda a nadie. En estos casos, si quieres dejar constancia, escríbela en lenguaje humano con -e:

Un tercer caso, para completar el catálogo de usos legítimos: te has equivocado de rama. Has hecho tres commits en main que debían ir en una rama de funcionalidad. La solución clásica es crear la rama donde estás, y devolver main a su sitio; pero si prefieres no tocar main, un cherry-pick de los tres commits a la rama correcta es una salida perfectamente válida. La casuística completa de "he confirmado en la rama equivocada" está en la lección 09-01.

Aquí es donde el cherry-pick pasa factura, y conviene entenderlo bien porque es la razón principal para no abusar de él.

Escenario: Bruno tiene funcionalidad/informe-semanal con cinco commits. Uno de ellos, 4d7c1a9, corrige un fallo que urge en producción ya. Bruno hace cherry-pick de ese commit a main:

Perfecto: el fallo está corregido en main y desplegado. Pero ahora, en el repositorio, el mismo cambio existe dos veces: como 4d7c1a9 en la rama de Bruno y como 2e9b6f3 en main.

Dos semanas después, Bruno termina la funcionalidad y fusiona su rama en main. ¿Qué pasa?

Caso bueno. Si nadie ha tocado esas líneas desde entonces, la fusión a tres bandas se da cuenta de que el cambio de 4d7c1a9 ya está aplicado en main (el resultado es el mismo por los dos lados) y la fusión sale limpia. El commit 4d7c1a9 entra en el historial, pero su contenido no se aplica dos veces. El resultado es correcto; simplemente el git log de main muestra dos commits que dicen lo mismo.

Caso malo. Si alguien ha modificado esas líneas en main después del cherry-pick, la fusión ve un cambio en theirs (el de 4d7c1a9) sobre una base que ya no coincide, y conflictúa. Es el conflicto más desconcertante que existe: los marcadores muestran dos versiones casi idénticas de un código que tú ya arreglaste, y no hay forma de entender por qué choca si no recuerdas el cherry-pick de hace dos semanas.

Caso peor. Si el cambio no es idempotente —añadir una línea a una lista, incrementar un contador, añadir una entrada a un fichero de configuración—, la fusión puede aplicarlo dos veces sin conflictuar. El resultado compila, pasa los tests superficiales y está mal.

La conclusión es la que da título al último apartado: cherry-pick es para cuando no vas a fusionar después, o para cuando fusionar no es una opción (ramas que nunca se juntan, como main y mantenimiento/1.x).

Git tiene herramientas para reconocer commits que introducen el mismo cambio con hashes distintos. Se basan en el patch-id: un hash calculado sobre el contenido del diff, ignorando el contexto, las líneas en blanco y los números de línea. Dos commits con el mismo patch-id hacen lo mismo aunque sean objetos distintos.

git cherry compara dos ramas y marca cada commit con + (no está en la otra) o - (ya está allí, con otro hash):

El - en la segunda línea significa: "este commit ya está aplicado en main, aunque allí tenga otro hash". Exactamente lo que buscábamos. La sintaxis es git cherry [-v] <upstream> [<head>], y -v añade el asunto de cada commit.

Es especialmente útil antes de fusionar o antes de portar un lote de commits a mantenimiento: te dice qué queda realmente por llevar.

git log --cherry-mark hace lo mismo dentro de un log, sobre un rango de tres puntos:

Ahí están, uno al lado del otro, los dos commits que hacen lo mismo. Variantes relacionadas:

--cherry-pick es el que usarás más: filtra el ruido y te deja solo el trabajo pendiente de verdad.

Una limitación honesta: el patch-id compara el diff. Si al hacer el cherry-pick hubo un conflicto y resolviste de forma distinta, el diff resultante no será idéntico y Git no lo reconocerá como equivalente. La detección es una ayuda, no una garantía.

La regla de decisión, en una frase: si las dos ramas van a acabar juntándose, no copies commits entre ellas; fusiónalas. El cherry-pick es para ramas que viven en paralelo permanentemente (mantenimiento, versiones antiguas, entornos separados) o para rescatar algo de una rama que va a morir.

Sobre la regla de oro: el cherry-pick es de las tres operaciones de este bloque la menos peligrosa, porque no reescribe nada. Añade un commit nuevo a la rama donde estás; no toca el origen ni obliga a nadie a forzar un push. Su peligro no es la reescritura sino la duplicación, que se paga más tarde y en forma de conflictos difíciles de explicar.

Error 1: creer que cherry-pick "mueve" el commit. Lo copia. El original sigue en su rama, tan vivo como antes. Si querías moverlo, tienes que borrarlo del origen con un rebase interactivo (drop), con las implicaciones de la regla de oro que eso conlleva.

Error 2: hacer cherry-pick de commits de una rama que después vas a fusionar. Es la fuente número uno de conflictos incomprensibles. Si la rama va a entrar entera, espera.

Error 3: olvidar -x al portar a mantenimiento. Dentro de seis meses, ese commit sin origen conocido en mantenimiento/1.x será un misterio. Cuesta dos caracteres.

Error 4: usar -x copiando de una rama local que vas a borrar. La referencia queda apuntando a un hash irresoluble. Ahí es mejor -e y una nota en lenguaje humano.

Error 5: hacer cherry-pick sin mirar el commit antes. git show <sha> cuesta tres segundos y te evita descubrir a mitad del conflicto que el commit tocaba seis ficheros y dependía de otros tres.

Error 6: no comprobar el rango. A..B excluye A. Si esperabas que se aplicaran cinco commits y se aplican cuatro, es esto. Comprueba siempre antes con git log --oneline A..B.

Error 7: confundir la dirección de git cherry. El primer argumento es el upstream (con lo que comparas, normalmente main) y el segundo la rama que examinas. Al revés te dará justo lo contrario de lo que esperas.

Consejo 1: haz commits pequeños y autocontenidos. No es un consejo sobre cherry-pick, es el consejo que hace posible el cherry-pick. Un commit que hace una sola cosa se trasplanta sin drama; uno que mezcla tres, no.

Consejo 2: verifica siempre después de portar. Que el parche se aplique sin conflicto no significa que funcione en la otra rama. Ejecuta las pruebas.

Consejo 3: usa git cherry -v antes de una campaña de portado. Te dirá exactamente qué queda por llevar y qué ya está, sin depender de tu memoria.

Consejo 4: para lotes grandes, git rebase --onto en lugar de muchos cherry-picks. Es la misma operación en el fondo, pero de una sola vez y con una lista clara de lo que se está reaplicando.

Consejo 5: si el cherry-pick se complica, aborta. git cherry-pick --abort deja el repositorio exactamente como estaba. Reconstruir el cambio a mano en la rama de destino es a veces más rápido y siempre más claro que pelear con un parche que no encaja.

Monta un repositorio con main y una rama mantenimiento/1.x que salga de un commit antiguo. Añade dos commits a main, uno de ellos una corrección pequeña. Después:

1. Porta solo la corrección a mantenimiento/1.x dejando constancia del origen.
2. Demuestra que el hash es distinto pero el diff es idéntico.
3. Demuestra que el autor original se ha conservado.

Provoca a propósito el problema del apartado 7:

1. Crea una rama con tres commits.
2. Haz cherry-pick del segundo a main.
3. Usa git cherry -v para demostrar que Git sabe que ese cambio ya está en main.
4. Usa git log --cherry-mark --left-right para ver los dos commits equivalentes marcados con =.
5. Fusiona la rama en main y observa qué pasa con el historial.

Con una rama que tenga cuatro commits pequeños, lleva los tres primeros a otra rama como un único commit con un mensaje propio, usando -n. Verifica con git show --stat que el commit resultante contiene los cambios de los tres.

Solución 1:

(Conflictúa porque en mantenimiento/1.x falta la línea de la funcionalidad. Se resuelve dejando solo la corrección.)

Hash distinto, misma autoría y misma fecha de autoría. El mensaje del nuevo incluye además la línea (cherry picked from commit 5c9e1f4...).

Solución 2:

Solo si el diff resultante coincide; si tu resolución del conflicto cambió el parche, aparecerá con +. Es la limitación que comentamos.

Verás el commit portado y el original conviviendo en el historial de main, diciendo lo mismo dos veces. Si el conflicto se resolvió de forma distinta, además habrá conflictuado al fusionar. Ese es exactamente el precio del cherry-pick prematuro.

Solución 3:

Fíjate en el rango: a27c9f3^..3b9d6a2 incluye Uno, Dos y Tres. Sin el ^ habrías portado solo Dos y Tres.

git cherry-pick es la herramienta de precisión del módulo. Lo esencial:

• Copia el cambio de un commit sobre tu rama actual creando un commit nuevo con otro hash. Conserva el mensaje, el autor y la fecha de autoría; tú pasas a ser el confirmador.
• Acepta commits sueltos y rangos, con la trampa habitual de que A..B excluye A y A^..B no. Los commits de fusión quedan fuera de los rangos.
• -x deja constancia del origen y es imprescindible al portar a ramas de mantenimiento públicas; -n permite acumular varios commits y confirmarlos como uno; -e edita el mensaje y -s añade el sign-off.
• Los conflictos se resuelven como siempre (lección 03-05) y se sale con --continue, --skip o --abort. Aquí ours y theirs NO están invertidos: la inversión era cosa del rebase.
• Los casos legítimos son dos: llevar una corrección a una rama que nunca se fusionará con el origen (mantenimiento, versiones antiguas), y rescatar un commit de una rama que se va a abandonar.
• El precio del abuso son los duplicados: si copias un commit de una rama que después fusionas, el mismo cambio acaba dos veces en el historial y, en el peor caso, aplicado dos veces.
• git cherry -v y git log --cherry-mark/--cherry-pick detectan cambios equivalentes comparando el patch-id, y son la forma de saber qué queda realmente por portar.
• Si las dos ramas van a juntarse, no copies: fusiona.

Las tres lecciones anteriores han manipulado commits: reaplicándolos, reorganizándolos, copiándolos. Todas parten de la misma premisa: que el trabajo ya está confirmado.

Pero el día a día tiene un problema distinto y muy frecuente. Estás a mitad de algo, con el fichero medio escrito y nada confirmable, y llega una urgencia que hay que atender ahora. No quieres confirmar un wip (aunque sea corregible con lo aprendido en 05-02), no quieres perder lo hecho, y necesitas el directorio limpio para cambiar de rama.

Git tiene un cajón para eso, y lo llevamos prometiendo desde la lección 03-02: git stash. Lo abrimos en la lección 05-04: Guardando Cambios Temporales.