Nombre

git-cherry-pick: aplica los cambios introducidos por algunas confirmaciones existentes

Sinopsis

git cherry-pick [--edit][-n][-m parent-number][-s][-x][--ff][-S[<keyid>]]<commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

Descripción

Dadas una o más confirmaciones existentes, aplique el cambio que introduce cada una, registrando una nueva confirmación para cada una. Esto requiere que su árbol de trabajo esté limpio (sin modificaciones de la confirmación HEAD).

Cuando no es obvio cómo aplicar un cambio, sucede lo siguiente:

  1. La rama actual y HEAD el puntero permanece en la última confirmación realizada con éxito.

  2. los CHERRY_PICK_HEAD ref se establece para apuntar a la confirmación que introdujo el cambio que es difícil de aplicar.

  3. Las rutas en las que el cambio se aplicó limpiamente se actualizan tanto en el archivo de índice como en su árbol de trabajo.

  4. Para rutas en conflicto, el archivo de índice registra hasta tres versiones, como se describe en la sección “FUSIÓN VERDADERA” de git-merge[1]. Los archivos del árbol de trabajo incluirán una descripción del conflicto entre corchetes por los marcadores de conflicto habituales <<<<<<< y >>>>>>>.

  5. No se realizan otras modificaciones.

Ver git-merge[1] para obtener algunas sugerencias sobre cómo resolver estos conflictos.

Opciones

...

Se compromete a elegir bien. Para obtener una lista más completa de formas de deletrear confirmaciones, consulte gitrevisions[7]. Se pueden pasar conjuntos de confirmaciones, pero no se realiza ningún recorrido de forma predeterminada, como si el --no-walk se especificó la opción, consulte git-rev-list[1]. Tenga en cuenta que especificar un rango alimentará a todos ... argumentos para un recorrido de revisión único (ver un ejemplo posterior que usa maint master..next).

-mi
--editar

Con esta opción, git cherry-pick le permitirá editar el mensaje de confirmación antes de realizar la confirmación.

--cleanup =

Esta opción determina cómo se limpiará el mensaje de confirmación antes de pasarlo a la maquinaria de confirmación. Ver git-commit[1] para más detalles. En particular, si el se le da un valor de scissors, se anexarán unas tijeras MERGE_MSG antes de transmitirse en caso de conflicto.

-X

Cuando grabe la confirmación, agregue una línea que diga "(seleccionado de confirmación ...)" al mensaje de confirmación original para indicar de qué confirmación se seleccionó este cambio. Esto se hace solo para selecciones de cereza sin conflictos. No use esta opción si está seleccionando en su sucursal privada porque la información es inútil para el destinatario. Si, por otro lado, está eligiendo entre dos ramas visibles públicamente (por ejemplo, exportando una solución a una rama de mantenimiento para una versión anterior de una rama de desarrollo), agregar esta información puede ser útil.

-r

Solía ​​ser que el comando no hacía -x descrito anteriormente, y -r fue desactivarlo. Ahora lo predeterminado es no hacer -x por lo que esta opción no es operativa.

-m padre-número
--número principal principal

Por lo general, no puede seleccionar una combinación porque no sabe qué lado de la combinación debe considerarse la línea principal. Esta opción especifica el número principal (a partir de 1) de la línea principal y permite que la selección rápida reproduzca el cambio en relación con el padre especificado.

-norte
--no comprometerse

Por lo general, el comando crea automáticamente una secuencia de confirmaciones. Esta bandera aplica los cambios necesarios para seleccionar cada compromiso con nombre en su árbol de trabajo y el índice, sin realizar ningún compromiso. Además, cuando se usa esta opción, su índice no tiene que coincidir con la confirmación HEAD. La selección selectiva se realiza contra el estado inicial de su índice.

Esto es útil cuando selecciona más de un efecto de confirmación en su índice en una fila.

-s
--cerrar sesión

Agrega un Signed-off-by tráiler al final del mensaje de confirmación. Ver la opción de firma en git-commit[1] para más información.

-S[]
--gpg-sign[=]
--no-gpg-sign

GPG-sign confirma. los keyid el argumento es opcional y por defecto es la identidad del autor; si se especifica, debe pegarse a la opción sin espacio. --no-gpg-sign es útil para contrarrestar tanto commit.gpgSign variable de configuración, y anterior --gpg-sign.

--ff

Si el HEAD actual es el mismo que el padre de la confirmación seleccionada, se realizará un avance rápido a esta confirmación.

--permitido-vacío

De forma predeterminada, la selección de una confirmación vacía fallará, lo que indica que una invocación explícita de git commit
--allow-empty es requerido. Esta opción anula ese comportamiento, lo que permite que las confirmaciones vacías se conserven automáticamente en una selección. Tenga en cuenta que cuando "--ff" está en vigor, las confirmaciones vacías que cumplen con el requisito de "avance rápido" se mantendrán incluso sin esta opción. Tenga en cuenta también que el uso de esta opción solo mantiene las confirmaciones que inicialmente estaban vacías (es decir, la confirmación registró el mismo árbol que su padre). Las confirmaciones que se hacen vacías debido a una confirmación anterior se descartan. Para forzar la inclusión de esas confirmaciones, use --keep-redundant-commits.

--permitir-mensaje-vacío

De forma predeterminada, la selección de una confirmación con un mensaje vacío fallará. Esta opción anula ese comportamiento, lo que permite seleccionar las confirmaciones con mensajes vacíos.

--keep-redundant-commits

Si una confirmación que se selecciona con precisión duplica una confirmación que ya está en el historial actual, se volverá vacía. Por defecto, estas confirmaciones redundantes causan cherry-pick detener para que el usuario pueda examinar la confirmación. Esta opción anula ese comportamiento y crea un objeto de confirmación vacío. Implica --allow-empty.

--strategy =

Utilice la estrategia de fusión dada. Solo debe usarse una vez. Consulte la sección MERGE STRATEGIES en git-merge[1] para detalles.

-X
--strategy-option =

Pase la opción específica de la estrategia de fusión a la estrategia de fusión. Ver git-merge[1] para detalles.

--rerere-autoupdate
--no-rerere-autoupdate

Permita que el mecanismo de repetición actualice el índice con el resultado de la resolución automática de conflictos si es posible.

Subcomandos del secuenciador

--Seguir

Continúe la operación en curso utilizando la información en .git/sequencer. Se puede usar para continuar después de resolver conflictos en una selección o reversión fallida.

--saltar

Omita la confirmación actual y continúe con el resto de la secuencia.

--dejar

Olvídese de la operación actual en curso. Se puede usar para borrar el estado del secuenciador después de una selección o reversión fallida.

--abortar

Cancele la operación y vuelva al estado de secuencia previa.

Ejemplos de

git cherry-pick master

Aplique el cambio introducido por la confirmación en la punta de la rama maestra y cree una nueva confirmación con este cambio.

git cherry-pick ..master
git cherry-pick ^HEAD master

Aplique los cambios introducidos por todas las confirmaciones que son ancestros del maestro pero no de HEAD para producir nuevas confirmaciones.

git cherry-pick maint next ^master
git cherry-pick maint master..next

Aplicar los cambios introducidos por todas las confirmaciones que son ancestros de maint o next, pero no master o cualquiera de sus ancestros. Tenga en cuenta que esto último no significa maint y todo entre master y next; específicamente, maint no se utilizará si está incluido en master.

git cherry-pick master~4 master~2

Aplique los cambios introducidos por la quinta y tercera últimas confirmaciones señaladas por el maestro y cree 2 nuevas confirmaciones con estos cambios.

git cherry-pick -n master~1 next

Aplique al árbol de trabajo y al índice los cambios introducidos por la penúltima confirmación señalada por master y por la última confirmación señalada por next, pero no cree ninguna confirmación con estos cambios.

git cherry-pick --ff ..next

Si el historial es lineal y HEAD es un antepasado de next, actualice el árbol de trabajo y avance el puntero HEAD para que coincida con el siguiente. De lo contrario, aplique los cambios introducidos por las confirmaciones que están en el siguiente pero no HEAD a la rama actual, creando una nueva confirmación para cada nuevo cambio.

git rev-list --reverse master -- README | git cherry-pick -n --stdin

Aplique los cambios introducidos por todas las confirmaciones en la rama maestra que tocó README en el árbol de trabajo y el índice, de modo que el resultado se pueda inspeccionar y convertir en una única confirmación nueva si es adecuado.

La siguiente secuencia intenta respaldar un parche, se rescata porque el código al que se aplica el parche ha cambiado demasiado, y luego vuelve a intentarlo, esta vez teniendo más cuidado en hacer coincidir las líneas de contexto.

$git cherry-pick topic^             (1)$gitdiff(2)$git reset --merge ORIG_HEAD        (3)$git cherry-pick -Xpatience topic^  (4)

  1. aplicar el cambio que mostraría git show topic^. En este ejemplo, el parche no se aplica de forma limpia, por lo que la información sobre el conflicto se escribe en el índice y el árbol de trabajo y no se obtienen nuevos resultados de confirmación.

  2. resumir los cambios que se van a conciliar

  3. cancelar la selección de cerezas. En otras palabras, regrese al estado previo a la selección selectiva, conservando las modificaciones locales que tuvo en el árbol de trabajo.

  4. tratar de aplicar el cambio introducido por topic^ de nuevo, dedicar más tiempo a evitar errores basados ​​en líneas de contexto que coinciden incorrectamente.

Ver también

git-revert[1]