¿Qué es Git Cherry-Pick?
Una corrección crítica acaba de llegar a tu branch de desarrollo -- pero el mismo bug está en producción. No puedes hacer merge de toda la branch de desarrollo en la branch de release, porque está llena de funcionalidades a medio terminar. Lo que realmente necesitas es tomar ese commit concreto y aplicarlo en otro lugar. Eso es exactamente lo que hace git cherry-pick.
El cherry-pick toma los cambios introducidos por un commit existente y los reproduce en tu branch actual como un commit completamente nuevo. El nuevo commit contiene el mismo diff y, por defecto, el mismo mensaje, pero tiene un padre diferente y por tanto un SHA diferente. Este detalle importa más de lo que parece: Git identifica los commits por su SHA, así que tras un cherry-pick tu repositorio contiene dos commits distintos que introducen el mismo cambio. Tenlo presente -- explica tanto por qué el cherry-pick es tan útil como por qué abusar de él causa problemas más adelante.
Cuándo el cherry-pick es la herramienta adecuada
Retroportar un hotfix a una branch de release
Es el caso clásico. Corregiste un bug en main, pero tus usuarios usan la versión 2.3 y necesitan la corrección ya. Haz cherry-pick de la corrección en la branch de release:
git switch release/2.3
git cherry-pick a1b2c3dLa branch de release recibe exactamente esa corrección, y nada más de main se cuela por el camino.
Un commit aterrizó en la branch equivocada
Querías hacer commit en tu branch de funcionalidad, pero estabas en main. El cherry-pick ofrece una recuperación limpia: cambia a la branch donde el commit debe estar, haz cherry-pick allí, y luego vuelve a eliminarlo de la branch donde no pinta nada. Si el paso de eliminación te genera dudas, nuestra guía sobre cómo deshacer un commit de Git cubre cada opción en detalle.
Rescatar una corrección de una branch abandonada
A veces un experimento no llega a ninguna parte, pero un commit en medio de la branch corregía un bug real. En lugar de hacer merge de una branch sin futuro, haz cherry-pick del único commit valioso en tu branch activa y deja que el resto del experimento se elimine en paz.
Uso básico
La forma más simple toma un solo commit:
git cherry-pick a1b2c3dGit aplica los cambios de ese commit y crea inmediatamente un nuevo commit en tu branch actual, reutilizando el mensaje original. También puedes pasar varios commits a la vez, y Git los aplica uno a uno, en el orden en que los listas:
git cherry-pick a1b2c3d f4e5d6cOpciones prácticas que deberías conocer
-x: registrar de dónde vino el commit
Al retroportar, más adelante querrás saber de dónde salió un commit. La opción -x añade una línea como (cherry picked from commit a1b2c3d...) al mensaje del nuevo commit:
git cherry-pick -x a1b2c3dConviértelo en hábito para cualquier cherry-pick entre branches públicas de larga vida. Dentro de seis meses, esa única línea te dirá al instante si una corrección llegó a una release y de dónde provino.
Tomar un rango de commits
Puedes hacer cherry-pick de un rango completo con la sintaxis de dos puntos:
git cherry-pick A..BCuidado: esto aplica los commits posteriores a A, hasta B incluido. El propio A queda excluido. Si quieres incluir A, escribe:
git cherry-pick A^..BEl ^ significa "el padre de A", lo que vuelve a meter A dentro del rango. Confundir estas dos sintaxis es uno de los errores más comunes con cherry-pick.
--no-commit: aplicar sin hacer commit
A veces quieres los cambios pero no un commit automático -- por ejemplo para combinar varios commits recogidos en uno solo, o para ajustar el resultado antes de hacer commit:
git cherry-pick --no-commit a1b2c3dLos cambios llegan a tu directorio de trabajo y al área de staging, y creas el commit tú mismo cuando estés listo.
Gestionar conflictos durante un cherry-pick
Un cherry-pick puede entrar en conflicto por la misma razón que un merge: el commit que estás recogiendo se escribió sobre un código distinto al de tu branch actual. Cuando eso ocurre, Git se detiene a mitad de la operación y marca los archivos en conflicto:
error: could not apply a1b2c3d... fix login timeout
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue"Ahora tienes tres salidas:
git cherry-pick --continue-- después de editar los archivos en conflicto y añadirlos al staging congit add, esto termina el cherry-pick y crea el commit.git cherry-pick --abort-- cancela toda la operación y devuelve tu branch al estado exacto en que estaba antes de empezar. No se pierde nada, no se aplica nada.git cherry-pick --skip-- al recoger varios commits, omite el actual y pasa al siguiente. Útil cuando un commit del rango resulta estar ya aplicado o ser irrelevante.
Resolver los conflictos en sí funciona exactamente igual que resolver un conflicto de merge: abre cada archivo en conflicto, elige entre los hunks enfrentados (o combínalos), elimina los marcadores de conflicto y añade el archivo al staging. Si los marcadores de conflicto todavía te intimidan, nuestra guía para resolver conflictos de merge de Git visualmente también se aplica a los cherry-picks.
Lo que NO debes hacer con cherry-pick
No hagas cherry-pick de branches enteras
Si te encuentras haciendo cherry-pick de cinco, diez, veinte commits de una branch a otra, detente. Para eso están merge y rebase. Ambos mueven trabajo entre branches mientras dejan que Git entienda la relación entre ellas, lo que mantiene las operaciones futuras simples y sin conflictos. Si no tienes claro cuál de los dos encaja en tu flujo de trabajo, nuestra comparativa de rebase vs merge repasa los pros y contras.
El historial duplicado te pasa factura después
Recuerda: un cherry-pick crea un commit nuevo con un SHA nuevo, y Git no guarda ningún registro formal de que los dos commits representan "el mismo cambio". Si haces cherry-pick de commits de una branch de funcionalidad a main y más tarde haces merge de esa branch de todos modos, Git tiene que reconciliar dos copias de los mismos cambios. A menudo lo consigue en silencio. Pero en cuanto alguna de las copias se modificó después, obtienes conflictos desconcertantes donde ambos lados parecen casi idénticos -- y tu historial muestra el mismo cambio dos veces, con dos fechas y dos SHA, lo que hace más difícil razonar con herramientas como git log y git bisect.
Una buena regla general: el cherry-pick sirve para mover excepciones -- un hotfix, un commit extraviado, una corrección rescatada. En el momento en que se convierte en tu forma rutinaria de mover trabajo entre branches, tu historial te está diciendo que la estrategia de branches necesita un replanteamiento.
El cherry-pick en GitSquid
En GitSquid, el cherry-pick está donde esperarías: haz clic derecho en cualquier commit del grafo de commits y elige la opción cherry-pick en el menú contextual. Sin copiar SHA de un lado a otro entre un log y un terminal.
La mayor ventaja es saber a qué te enfrentas. El Conflict Predictor de GitSquid -- gratuito para todos -- muestra exactamente qué archivos entrarán en conflicto antes de ejecutar un merge, rebase o cherry-pick, con vistas previas de los hunks y resaltado de sintaxis. En lugar de descubrir los conflictos a mitad de una operación, los ves de antemano y puedes decidir si continuar, elegir otro commit o preparar la resolución con calma.
Y cuando un cherry-pick sí entra en conflicto, "Resolve in scratch worktree" abre un worktree temporal como una nueva pestaña, para que puedas resolverlo todo allí mientras tu checkout activo permanece intacto.
Referencia rápida
| Comando | Qué hace |
|---|---|
git cherry-pick <sha> |
Aplica un commit en la branch actual |
git cherry-pick <sha1> <sha2> |
Aplica varios commits, en orden |
git cherry-pick -x <sha> |
Añade el SHA de origen al mensaje del commit |
git cherry-pick A..B |
Toma los commits después de A hasta B (A excluido) |
git cherry-pick A^..B |
Toma el rango incluyendo A |
git cherry-pick --no-commit <sha> |
Aplica los cambios sin hacer commit |
git cherry-pick --continue |
Termina el pick tras resolver los conflictos |
git cherry-pick --abort |
Cancela y restaura la branch tal como estaba |
git cherry-pick --skip |
Omite el commit actual, continúa con el resto |
El cherry-pick es un bisturí, no una pala. Usado para la extracción precisa y ocasional -- un retroporte de hotfix, un commit extraviado, una corrección rescatada -- es uno de los comandos más satisfactorios de Git. Usado como sustituto del merge, llena silenciosamente tu historial de duplicados que vuelven para atormentarte. Conoce la diferencia, añade -x cuando retroportes, y ten presente --abort como salida de emergencia.
¿Quieres ver qué archivos entrarán en conflicto antes incluso de empezar? Descarga GitSquid gratis y deja que el Conflict Predictor elimine las conjeturas de tu próximo cherry-pick.