A veces el cambio que necesitas ya existe, sólo que en la rama equivocada. Cuando un parche también necesita ir a la rama de lanzamiento, o una confirmación útil está oculta en una rama de características que no desea fusionar de forma masiva, cae en el tronco. gitcherry-pick copia los efectos de una confirmación específica en la rama actual sin tocar nada más.
Cómo utilizar git Cherry-pick:
La sintaxis es:
bash
git cherry-pick [OPTIONS] COMMIT...
COMMIT can be a hash, a branch reference, or a range. git cherry-pick replays the changes introduced by the selected commit on top of your current branch and creates a new commit. The new commit has a different hash even when the file changes are identical — because the parent commit is different.
Utilice git log –oneline en la rama fuente para encontrar la confirmación deseada:
bash
git log --oneline feature/auth
Primero cambie a la rama de destino y luego ejecute cherry-pick:
bash
git switch main
git cherry-pick a3f1c92
Git aplica los cambios en a3f1c92 y crea una nueva confirmación 9b2d4f1. La línea de asunto permanece, pero el hash es nuevo.
Seleccione cuidadosamente múltiples confirmaciones y alcances
Las confirmaciones no consecutivas pasan hashes en el orden en que desea que Git los aplique. Git crea una confirmación separada para cada uno:
bash
git cherry-pick a3f1c92 d8b22e1
Rango continuo. El cursor determina si se incluye el compromiso inicial:
git cherry-pick a3f1c92^..7c4e003 # includes a3f1c92 through 7c4e003
git cherry-pick a3f1c92..7c4e003 # excludes a3f1c92; starts from the commit after it
The caret (^) means "include this commit". Without it, the starting commit is excluded and Git applies only the commits that come after it.
Opciones útiles: –no-commit, -x y fusionar confirmaciones
–no-commit (o -n) aplica cambios al árbol de trabajo y al área de preparación sin crear una confirmación. Utilice esta opción cuando desee combinar varias selecciones en una sola confirmación o ver los resultados antes de finalizar:
git cherry-pick --no-commit a3f1c92
git commit -m "Backport auth null-check fix"
-x records the source commit hash in the new commit message automatically:
git cherry-pick -x a3f1c92
El mensaje de envío incluirá:
Esta es una buena práctica para el backporting. Crea un seguimiento de auditoría claro y facilita la prueba de que una solución en una rama de lanzamiento proviene de una confirmación revisada en otra rama.
Las confirmaciones de fusión requieren la opción -m para indicarle a Git qué línea principal usar como línea principal:
git cherry-pick -m 1 MERGE_COMMIT_HASH
-m 1 Utilice la primera rama principal que recibió la combinación. -m 2 usa el segundo. Si no está seguro de cuál padre es cuál, primero use git log –oneline –graph para verificar el historial. Elegir confirmaciones de fusión es más propenso a errores que elegir confirmaciones regulares. Si el objetivo es ofrecer toda la funcionalidad de combinación, la combinación normal suele ser la opción más clara.
Resuelva conflictos y siga un flujo de trabajo de backport seguro
Cuando la rama de destino tiene cambios conflictivos en la misma región de código, Git se detiene e informa el problema:
Error: no se puede aplicar a3f1c92…corregir el puntero nulo en el controlador de validación
Consejo: después de resolver los conflictos, ejecute «gitcherry-pick –continue»
Abra el archivo de conflicto, resuelva las banderas de conflicto, prepare los resultados y continúe:
git add src/auth.js
git cherry-pick --continue
Para cancelar la operación y devolver la sucursal al estado exacto en el que se encontraba antes de iniciar el retiro:
git cherry-pick --abort
Flujo de trabajo de backport seguro. Al elegir una rama de versión o mantenimiento, siga esta secuencia:
git switch release/1.4
git pull --ff-only # ensure the branch is up to date first
git cherry-pick -x a3f1c92 # pick with -x for traceability
git status # review before pushing
git pull –ff-only fallará intencionalmente si la rama se desvía de su origen, lo cual es una verificación de seguridad útil. Si la confirmación seleccionada depende de una refactorización o API que no existe en la rama de destino, deténgase. Priorice los requisitos previos que se confirmaron primero o restablezca manualmente la solución.
Cuándo usar (y evitar) gitcherrypick
Genial para:
Corrección de errores de backport desde la rama maestra hasta la rama de lanzamiento
Recuperar una confirmación útil de una rama de función abandonada
Mover correcciones que se confirmaron en la rama incorrecta
Introduzca los cambios revisados en ramas de parches sin fusionar trabajos no relacionados
Evite usarlo cuando la confirmación dependa de una confirmación anterior, una refactorización compartida o un cambio de esquema que falta en la rama de destino. Fusionar o cambiar la base es una mejor opción cuando la rama de destino requiere el contexto completo de la rama de origen.
Use gitcherry-pick HASH para una solución única, use A^..B para un rango contiguo, -x para cualquier backport que desee rastrear o –abort si la operación sale mal. Si tiene algún problema, deje un comentario a continuación.
