Git cherry-pick: copia una confirmación a otra rama y soluciona conflictos

Git cherry-pick aplica el cambio introducido por una confirmación a su rama actual, generalmente registrando una nueva confirmación. Cambie a la rama que debería recibir la corrección, inspeccione la confirmación de origen y luego ejecute git cherry-pick <commit>. La rama de origen permanece en su lugar. Si el parche entra en conflicto, resuelva los archivos y continúe o cancele la operación.

Imagine un error de pago solucionado en feature/checkout, mientras que una rama de lanzamiento solo necesita esa corrección. Fusionar toda la función podría generar trabajo sin terminar. Esta guía muestra cómo copiar solo la solución con Git y con GitTree, el cliente que creamos para macOS, Windows y Linux. El valor adicional de la ruta visual es verificar la rama de destino y la diferencia de origen antes de aplicar el cambio.

Cherry-pick vs merge vs rebase: elija la operación

Cherry-pick es útil para un backport o una pequeña corrección enviada a la rama equivocada. Es un mal sustituto de la fusión repetida de dos ramas que deberían compartir todo su trabajo: los cambios copiados pueden resultar difíciles de rastrear. Para ver un flujo de trabajo de toda la rama, consulte rebase interactiva y la guía de gráficos de confirmación.

Cómo seleccionar un compromiso en otra rama

Comience con un árbol de trabajo limpio. Confirmar o guardar ediciones inacabadas; la guía de almacenamiento cubre ese flujo de trabajo de pausar y reanudar. Busque si la solución es remota y luego inspeccione el historial de origen. Los nombres de las ramas y el hash a continuación son ejemplos: reemplácelos con una rama de destino existente, su rama de origen y el hash de corrección real.

git status
git fetch origin
git log --oneline origin/feature/checkout
git show abc1234
git switch release/2.x
git status
git cherry-pick -x abc1234
git show --stat HEAD
git status

-x agrega la referencia de confirmación de origen al mensaje para una selección limpia, lo que ayuda a rastrear los backports públicos. Obtener actualizaciones de referencias de seguimiento remoto; no actualiza automáticamente su rama de versión desprotegida. Confirme que el destino esté en la revisión que espera su equipo. Revise la nueva confirmación y ejecute las pruebas de la rama de lanzamiento antes de enviarla.

La confirmación elegida normalmente tiene un hash diferente porque su padre y otros metadatos de confirmación difieren. Su original permanece en la rama fuente. Copiar una corrección no la elimina de la rama equivocada; Decidir cómo limpiar esa rama es una decisión histórica separada, especialmente si otras personas ya la usan.

Descargue GitTree para seguir este flujo de trabajo con un gráfico visual y un editor de conflictos. Cherry-pick está incluido en el plan gratuito, incluidos los repositorios privados. Inicie sesión en la aplicación oficial actual, abra su repositorio existente y use el mismo historial de Git que ya tiene.

Seleccione múltiples confirmaciones y rangos

git cherry-pick abc1234 def5678
# A linear range, including the first commit:
git cherry-pick "abc1234^..def5678"

Estos son ejemplos alternativos. Una lista explícita selecciona las confirmaciones en el orden proporcionado; ponga primero los cambios de requisitos previos. Un rango sigue reglas de conjuntos de revisiones en lugar de seleccionar las filas que ves en un gráfico. A..B excluye A; A^..B incluye A para una secuencia lineal simple cuando A tiene un padre. Para un backport para principiantes, prefiera una lista explícita y revisada en lugar de un rango que abarque fusiones.

Resuelva conflictos selectos y continúe

Cuando Git no puede aplicar el parche, se detiene. Ejecute git status para identificar la operación y las rutas en conflicto, luego edite el resultado deseado. Utilice la guía de resolución de conflictos para ver ejemplos de marcadores y el editor de tres vías GitTree. Una resolución sintácticamente limpia aún necesita pruebas: el destino puede utilizar diferentes API.

git status
git diff --name-only --diff-filter=U
# Resolve the file, then check and stage it:
git diff --check
git add -- src/payment.ts
git diff --cached
git cherry-pick --continue

Una secuencia puede pausarse más de una vez, una vez por cada confirmación problemática. Si Git dice que la selección está vacía, inspeccione si el cambio ya está presente o si su resolución lo eliminó. Utilice git cherry-pick --skip sólo cuando desee omitir deliberadamente esa confirmación; no es una solución general para un conflicto.

Git selección selectiva de aborto, salida y omisión

Fusionar confirmaciones, dependencias faltantes y deshacer una selección

Una confirmación de fusión necesita un padre principal porque representa cambios relativos a más de un padre. Inspeccione con git show --no-patch --pretty=raw <merge> antes de considerar git cherry-pick -m 1 <merge>. El padre 1 no es universalmente correcto. GitTree le pide que seleccione el padre; elija por la historia con la que desea comparar, no por hábito. A menudo es más fácil razonar sobre la elección de la confirmación de corrección ordinaria original.

Si la solución copiada se compila incorrectamente, inspeccione sus requisitos previos: un asistente, un cambio de esquema o una configuración pueden estar en una confirmación anterior. Una operación exitosa de Git solo prueba que se aplicó el parche. Pruebe la rama receptora. Para deshacer una selección finalizada en el historial compartido, revierta la nueva confirmación creada en la rama de destino, no el hash de origen original. Para trabajos no publicados, revise las opciones de restablecimiento y recuperación en deshacer errores de Git antes de mover el historial de sucursales.