Git cherry-pick: cómo pasar un commit a otra rama sin copiar todo

Publicado el 2026-10-26 por frfrand

Mover una corrección puntual entre ramas con Git cherry-pick

Git cherry-pick: cómo pasar un commit a otra rama sin copiar todo

Corregiste un bug en una rama, pero también lo necesitás en producción y no querés llevarte todos los cambios de esa rama. Ahí aparece git cherry-pick: toma el efecto de uno o varios commits y lo aplica sobre la rama actual.

La idea es usarlo para resolver un problema de verdad, no memorizar comandos porque quedan bien en una captura. Vamos con lo esencial, un ejemplo de trabajo y los errores que más conviene evitar.

Qué hace Git cherry-pick y cuándo sirve

No mueve literalmente el objeto commit original a la otra rama: normalmente crea un commit nuevo con otro hash y los cambios equivalentes. Por eso sirve para backports, no para reemplazar una estrategia ordenada de merge.

Si estás aprendiendo, probalo primero en un repositorio o entorno de prueba. Si administrás producción, documentá el estado antes de ejecutar nada que altere archivos, historial o datos. Eso te permite entender qué cambió y recuperarte si te equivocás.

Ejemplo para copiar y entender

git log --oneline -5
git switch main
git cherry-pick -x abc1234
# Si hay conflictos: resolver archivos, luego
git add .
git cherry-pick --continue
# Para abandonar la operación
git cherry-pick --abort

No copies la orden final sin mirar el estado previo. Los nombres de ramas, host, usuario o rutas son ejemplos; reemplazalos por los de tu proyecto. Algunos comandos modifican archivos o hacen peticiones que pueden escribir datos.

Cómo lo usaría paso a paso

  1. Paso 1. Encontrá el hash de la corrección con git log --oneline.
  2. Paso 2. Confirmá que estás en la rama destino, idealmente con pruebas pasando.
  3. Paso 3. Ejecutá git cherry-pick -x HASH si querés dejar constancia del origen en el mensaje.
  4. Paso 4. Si hay conflictos, corregilos, revisá el diff y continuá; no aceptes ambas versiones a ciegas.
  5. Paso 5. Corré pruebas y desplegá sólo después de comprobar el comportamiento.

Detenete después de cada paso y comprobá el resultado. Si algo falla, anotá el mensaje exacto antes de cambiar de estrategia. Saltar entre cinco soluciones aleatorias suele dificultar encontrar la causa real.

Un caso que podría pasarte trabajando con clientes

La rama desarrollo incluye rediseño de panel, pero solucionaste un error de validación de reservas. En vez de fusionar el rediseño incompleto, aplicás sólo el commit de la validación sobre la rama estable.

El objetivo no es que «funcione una vez», sino que puedas explicar cómo lo repetís sin comprometer otra aplicación. Si hay datos o credenciales de clientes, trabajá con pruebas separadas y accesos mínimos.

El error que más veo

Si el commit depende de otros cambios que no existen en destino, cherry-pick puede fallar o compilar con comportamiento incorrecto. Probá siempre las dependencias y no lo uses para copiar decenas de commits relacionados sin revisar.

Una regla sencilla: si no podés explicar qué hará el comando sobre tu código o servidor, mirá primero su ayuda oficial. Así evitás confundir una solución rápida con un problema nuevo.

¿Dónde entra ArduMaker?

Al desplegar desde Git con ArduMaker, podés identificar qué commit está publicado. Esto facilita corregir un incidente con un cherry-pick y mantener la revisión de producción separada del desarrollo incompleto.

Por ejemplo, podés desplegar desde un repositorio Git a un VPS, asociar un dominio HTTPS y administrar servicios y bases desde el mismo entorno. El panel reduce tareas repetitivas de infraestructura, pero no reemplaza Git, las pruebas ni la revisión de permisos del proyecto.

Preguntas rápidas antes de aplicarlo

¿Esto cambia producción? Depende de dónde ejecutes la acción. Probá localmente primero, identificá el commit o servicio afectado y prepará un plan de recuperación.

¿Cómo compruebo que salió bien? No te quedes con la ausencia de mensajes de error: revisá el estado, ejecutá un test funcional y comprobá los logs o el historial correspondiente.

¿Conviene automatizarlo? Si es repetible y tiene resultados verificables, sí. Pero la automatización debería fallar de forma clara y no esconder errores o credenciales.

Para ampliar

Resumen: la herramienta útil no es la que tiene más opciones, sino la que te permite entender qué cambió, comprobarlo y seguir trabajando sin sorpresas.

  • Git
  • Tutorial
  • ArduMaker

Seguir leyendo

Todos los artículos · Planes de VPS