Git cherry-pick: qué es, cuándo usarlo y por qué es tan importante en el desarrollo de software
Git cherry-pick: traer solo lo que necesitas (y nada más)
En algún momento de tu vida como desarrollador te va a pasar esto:
- hay un bug crítico en producción 🧨
- el fix ya existe… pero está en otra rama
- no quieres mergear todo
- solo necesitas ese commit
Ahí es donde git cherry-pick deja de ser un comando raro y se convierte en una herramienta clave de supervivencia.
Qué es git cherry-pick (explicado sin humo)
git cherry-pick te permite aplicar uno o varios commits específicos de otra rama en la rama actual, sin traer todo el historial.
Dicho simple:
“Quiero este cambio puntual, no todo el árbol”.
No es merge. No es rebase. Es copiar un commit exacto y aplicarlo donde tú decidas.
El problema que resuelve (muy común en equipos reales)
Imagina este escenario:
main: produccióndevelop: trabajo activo- un bug se arregló en
develop developaún no está listo para mergear
Hacer merge sería arriesgado. Esperar no es opción.
Ahí entra cherry-pick.
Uso básico de git cherry-pick
El flujo básico es así:
- Te mueves a la rama destino
- Aplicas el commit que necesitas
git checkout main
git cherry-pick <hash-del-commit>Eso crea un nuevo commit en main con los mismos cambios.
⚠️ Importante: no es el mismo commit, es una copia con un nuevo hash.
Cherry-pick de varios commits
También puedes aplicar más de uno:
git cherry-pick <hash1> <hash2>O incluso un rango:
git cherry-pick A..BEsto aplica todos los commits después de A hasta B, inclusive.
Qué pasa si hay conflictos (spoiler: puede pasar)
Como cualquier operación que aplica cambios, cherry-pick puede generar conflictos.
Cuando pasa:
- Git se detiene
- Resuelves conflictos manualmente
- Confirmas el cherry-pick
git status
git add .
git cherry-pick --continueSi decides abortar:
git cherry-pick --abortNada explotó. Todo vuelve atrás. 😌
Cuándo usar git cherry-pick (y cuándo no)
Úsalo cuando:
- necesitas un fix puntual urgente
- quieres llevar un commit específico a otra rama
- trabajas con hotfixes
- quieres evitar merges grandes y riesgosos
Evítalo cuando:
- los commits están muy acoplados
- estás replicando cambios constantemente
- el flujo se vuelve “copiar y pegar commits”
Si usas cherry-pick todos los días, probablemente hay un problema de workflow.
Un error común: abusar del cherry-pick
Cherry-pick no reemplaza un buen flujo de ramas.
Problemas típicos por abuso:
- commits duplicados en varias ramas
- historial confuso
- fixes aplicados varias veces
- difícil trazabilidad
Recuerda: cherry-pick es un bisturí, no una motosierra.
Cherry-pick vs merge vs rebase (rápido y claro)
- merge: une historiales completos
- rebase: reescribe historia para linealidad
- cherry-pick: copia cambios específicos
Cada uno tiene su lugar. Cherry-pick es el más quirúrgico.
Un ejemplo real de uso responsable
Bug crítico detectado en producción:
- Fix se hace en
develop - Se revisa y aprueba
- Se cherry-pickea solo ese commit a
main - Se deploya
developsigue su curso normal
Resultado:
- producción estable
- sin mezclar features incompletas
- sin estrés innecesario
Pensar git cherry-pick como herramienta de control
Más que un comando, git cherry-pick es una forma de pensar:
“¿Qué cambio exacto quiero mover y por qué?”
Usado con criterio:
- te ahorra tiempo
- reduce riesgos
- mejora la calidad del flujo
Usado sin pensar:
- genera deuda
- confunde al equipo
En el día a día, cherry-pick bien usado se nota
No se nota cuando está bien hecho. Se nota cuando falta.
Cuando sabes usar git cherry-pick, tienes una herramienta más para responder rápido, sin romper cosas, y sin sacrificar orden.
Y eso, en desarrollo de software real, vale oro. 💎