Cherry-picking: cuándo encaja y qué le cuesta al historial

Qué es

git cherry-pick <commit> aplica el cambio que introduce un commit sobre la rama actual y registra un nuevo commit. La documentación exige un árbol de trabajo limpio, se detiene ante conflictos con CHERRY_PICK_HEAD establecido hasta --continue, --skip o --abort, y ofrece -x para añadir al mensaje una línea "(cherry picked from commit ...)". Aplicar un pick sobre un commit de merge requiere -m <parent-number> para indicar cuál padre es la línea principal. -n / --no-commit aplica varios picks al índice antes de un solo commit.

Por qué importa

El nuevo commit tiene el mismo parche pero un ID y un padre distintos. Git compara commits por ascendencia, de modo que un merge posterior de la rama de origen no sabe que el cambio ya está presente: un cambio idéntico en ambos lados suele fusionarse sin problemas, pero cualquier diferencia (un conflicto resuelto durante el pick, una edición posterior de las mismas líneas) se convierte en conflicto, y el historial conserva de todos modos dos commits para un solo cambio. Cada pick añade así un costo pequeño y permanente: un historial que debe reconciliarse por el contenido del parche y no por la ascendencia. git log --cherry-pick --left-right A...B existe precisamente para omitir los commits que introducen el mismo cambio en el otro lado, tal como describe la documentación de git-log.

Cómo aplicarlo

• Retroportar una corrección: hacer el commit de la corrección en la rama soportada más antigua y fusionar hacia arriba, o aplicarle un pick hacia abajo con -x para que el origen siga siendo rastreable. La documentación recomienda -x para picks entre ramas públicas y desaconseja usarlo entre ramas privadas.
• Rescatar un buen commit de una rama que se va a descartar: aplicarle el pick y luego eliminar la rama, para que no quede un linaje duplicado.
• Si se quiere una rama entera: fusionarla o rebasarla. Aplicar un pick a cada commit de una rama produce un segundo linaje de los mismos cambios que un merge posterior no puede reconocer como ya integrado.
• Corrección urgente publicada desde una rama de release: aplicar el pick a main de inmediato, antes de que ambas diverjan más.
• Mantener los commits con pick pequeños y autocontenidos; un pick de la mitad de una refactorización entrará en conflicto más tarde con la otra mitad.

Trampas

Un pick de un commit que depende de commits anteriores sin aplicar compila por suerte o no compila en absoluto. La resolución de conflictos durante un pick no queda registrada en ningún lugar salvo en el nuevo commit. Bisecar una rama hecha de picks apunta a la copia, no a la discusión original, a menos que estén presentes las líneas de -x. Los picks repetidos entre ramas de larga vida son una señal de que hay que cambiar el modelo de ramificación, no la herramienta.