Git cherry-pick: una copia, nunca un traslado

■ la respuesta primero

git cherry-pick <sha> copia un commit — mismo patch, SHA nuevo, nada se mueve.

Un rango excluye su inicio: A^..B incluye A, A..B lo salta en silencio.

¿Parado en un conflicto? Resuelve, git add, git cherry-pick --continue — hasta entonces estás a mitad de secuencia.

LA COPIA, DIBUJADA

Un arreglo que vive en una rama feature; main lo necesita ya. El pick repite el patch, acuña un SHA nuevo y deja el original exactamente donde estaba:

fig — copiar, no trasladar: borra la rama feature cuando quieras; la copia pickeada tiene su propio SHA y ninguna dependencia del viejo

LOS TRES PASOS

Encontrar el SHA, cambiar a la rama destino, pickear — el pick aterriza donde apunte HEAD:

# 1. locate the commit on the source branch
git log feature/payment-fix --oneline -5

# 2. switch to the branch that should receive it
git switch main

# 3. copy it over
git cherry-pick 1a2b3c4

verify: git log -1 --stat → el cambio pickeado, SHA nuevo, en la rama destino

Dos comodidades que valen conocer: git cherry-pick <branch> picka el tip de esa rama — cómodo, pero fácil de provocar por accidente con una imagen mental caducada de qué es «el tip». Y tras cualquier pick, git log -1 --stat confirma lo que aterrizó: un segundo de lectura, ahorra un revert.

MÚLTIPLES COMMITS

Tres formas, en orden de cuál querrás más a menudo — todas cruzan ramas, pues los SHA se resuelven contra el repositorio entero:

# 1. explicit list — picked in the order you list them
git cherry-pick 1a2b3c4 5d6e7f8

# 2. range — everything after A up to and including B
git cherry-pick A..B

# 3. range including A
git cherry-pick A^..B

verify: git log --oneline -4 tras el pick → ambos commits repetidos en orden, el más viejo primero

La distinción entre A..B y A^..B es la sorpresa clásica: A..B excluye A. Visualiza el rango desde git log, picka oldest..newest, y saltas el commit más viejo en silencio — oldest^..newest hace desaparecer el off-by-one. Para plegar varios picks en un solo commit en vez de tres, deja en stage sin commitear con -n / --no-commit, y luego un solo commit:

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

«POR QUÉ NO FUNCIONA» — LAS CUATRO CAUSAS

Un conflicto paró el pick. Git aplica el patch, topa con una línea cambiada en ambas ramas, y pausa a mitad de secuencia. Resuelve los ficheros, luego git add <resolved-files> y git cherry-pick --continue — o --abort para volver al estado previo al pick. --continue no es opcional ni está implícito: hasta que lo corras, git status sigue diciendo You are currently cherry-picking.
El pick está vacío («The previous cherry-pick is now empty») — el cambio ya existe en esta rama, a menudo de un pick anterior o de un merge squashado. Sáltalo con git cherry-pick --skip, o fuerza un marcador vacío con --allow-empty.
El commit es un commit de merge. Un merge tiene dos padres, así que «aplica este diff» es ambiguo — git se niega antes que adivinar. Di contra qué padre estás diferenciando: git cherry-pick -m 1 <merge-sha>. Los padres se numeran en el orden en que git los registró: parent 1 es la rama en la que estabas al mergear, parent 2 es la rama que entró — -m 1 es casi siempre lo que quiere un backport.
árbol de trabajo equivocado o HEAD suelta. El pick aterriza donde apunte HEAD. git branch --show-current antes de pickear; si no imprime nada, estás en HEAD detached y el commit quedará huérfano al cambiar de rama.

PICK VS MERGE VS REBASE

Comando	Lo que aterriza en el destino	Historia	Cuándo usarlo
`git cherry-pick <sha>`	Solo commit(s) nombrados	Copia, SHA nuevos	Un arreglo concreto debe moverse ya
`git merge <branch>`	Todo lo de la rama	Commit de merge o fast-forward	Quieres la rama entera, divergencia visible
`git rebase <base>`	Todos los commits de la rama, repetidos	Lineal, SHA reescritos	Quieres la rama como una corrida lineal limpia
`git revert <sha>`	La inversa de un commit	Añade un commit de undo	Un commit aterrizado debe deshacerse en historia compartida

La regla de una línea: cherry-pick traslada una selección; merge y rebase traslada todo. Recurrir a cherry-pick para «sincronizar» con una rama es señal de que en realidad quieres un merge. Un hábito que saltarse: pickear el mismo commit en varias ramas a largo plazo — cada arreglo futuro en la rama fuente exigirá otro pick, y las ramas acaban derivando. Los backports a ramas de release son un patrón normal; un universo paralelo permanente, no.

EL FLUJO, CONDENSADO

git log <source-branch> --oneline -5   # find the SHA(s)
git switch <target-branch>             # land in the right place
git cherry-pick A^..B                  # range, list, or single SHA
# on conflict: resolve → git add → git cherry-pick --continue
git log -1 --stat                      # confirm what landed

Encontrar, cambiar, pickear, verificar. El comando tiene fama de peligro que no merece — el diff se aplica, o se detiene y te dice por qué. El único error genuinamente destructivo es pickear en la rama equivocada, y git log -1 antes de empujar lo vuelve difícil de no ver.

■ sello honesto cherry-pick · copia-sin-traslado · merge/rebase para ramas enteras. Primera publicación 2026-09-12, ficha actualizada el 2026-10-10. Cada comando corre como impreso en cualquier git reciente; la semántica del rango (A..B excluye A), el comportamiento de pick vacío y la -m numeración de padres son comportamiento documentado de git, tecleados desde picks que aterrizaron de verdad.

fin de la página del pick · nada se descargó · todo es local