git-cherry-pick: en línea en la nube

PROGRAMA:

NOMBRE

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

SINOPSIS

git cherry-pick [--editar] [-n] [-m número-principal] [-s] [-x] [--ff]
[-S[ ]] ...
git cherry-pick --Seguir
git cherry-pick --dejar
git cherry-pick --abortar

DESCRIPCIÓN

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

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

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

2. La referencia CHERRY_PICK_HEAD 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
tu á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 un
descripción del conflicto entre paréntesis con los marcadores de conflicto habituales <<<<<<< y
>>>>>>>.

5. No se realizan otras modificaciones.

See git-merge(1) para obtener algunas sugerencias sobre cómo resolver dichos conflictos.

CAMPUS

...
Se compromete a elegir bien. Para obtener una lista más completa de formas de deletrear confirmaciones, consulte
gitrevisiones(7). Se pueden pasar conjuntos de confirmaciones, pero no se realiza ningún recorrido de forma predeterminada, como
si el --no caminar se especificó la opción, consulte git-rev-lista(1). Tenga en cuenta que especificar un
el rango alimentará a todos ... argumentos para una sola revisión (ver más adelante
ejemplo que usa mant maestro .. siguiente).

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

-x
Al grabar la confirmación, agregue una línea que diga "(selección de la cereza de la confirmación ...)"
al mensaje de confirmación original para indicar qué confirmación de este cambio fue
escogido de cereza. Esto se hace solo para selecciones de cereza sin conflictos. No utilice
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
bifurcaciones visibles públicamente (p. ej., trasportar una solución a una bifurcación de mantenimiento para una
versión de una rama de desarrollo), agregar esta información puede ser útil.

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

-m número-padre, --número-padre-principal
Por lo general, no puede seleccionar una combinación porque no sabe de qué lado de la combinación
debe considerarse la línea principal. Esta opción especifica el número principal (comenzando
desde 1) de la línea principal y permite seleccionar con precisión para reproducir el cambio en relación con el
padre especificado.

-n, --no-comprometerse
Por lo general, el comando crea automáticamente una secuencia de confirmaciones. Esta bandera aplica el
cambios necesarios para seleccionar cada compromiso con nombre en su árbol de trabajo y el índice,
sin hacer ningún compromiso. Además, cuando se utiliza esta opción, su índice no
tiene que coincidir con la confirmación HEAD. La selección de cereza 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 un
fila.

-s, --firmar
Agregue la línea Signed-off-by al final del mensaje de confirmación. Ver la opción de firma en
compromiso de git(1) para obtener más información.

-S[ ], --gpg-sign [= ]
GPG-sign confirma. El argumento keyid es opcional y el valor predeterminado es el confirmador.
identidad; si se especifica, debe pegarse a la opción sin un espacio.

--ff
Si el HEAD actual es el mismo que el padre de la confirmación seleccionada, entonces un
Se realizará un avance rápido hasta esta confirmación.

--permitido-vacío
De forma predeterminada, la selección de una confirmación vacía fallará, lo que indica que una
Se requiere la invocación de git commit --allow-empty. Esta opción anula eso
comportamiento, permitiendo que las confirmaciones vacías se conserven automáticamente en una selección. Nota
que cuando "--ff" está en vigor, confirmaciones vacías que cumplen con el requisito de "avance rápido"
se mantendrá incluso sin esta opción. Tenga en cuenta también que el uso de esta opción solo mantiene
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 usa --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.

--mantener-confirmaciones-redundantes
Si una confirmación que se selecciona con precisión duplica una confirmación que ya está en el historial actual,
se vaciará. De forma predeterminada, estas confirmaciones redundantes hacen que la selección selectiva se detenga, por lo que
el usuario puede examinar la confirmación. Esta opción anula ese comportamiento y crea un vacío
cometer objeto. Implica --permitido-vacío.

--strategy =
Utilice la estrategia de fusión dada. Solo debe usarse una vez. Ver las ESTRATEGIAS DE FUSIÓN
sección en git-merge(1) para obtener más detalles.

-X , --strategy-option =
Pase la opción específica de la estrategia de fusión a la estrategia de fusión. Ver git-
unir(1) para obtener más detalles.

SECUENCIADOR SUBCOMANDAS

--Seguir
Continúe la operación en curso utilizando la información en .git / secuenciador. Puede ser
utilizado para continuar después de resolver conflictos en una selección o reversión fallida.

--dejar
Olvídese de la operación actual en curso. Puede usarse para borrar el secuenciador
estado después de una selección o reversión fallida.

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

EJEMPLOS

maestro git cherry-pick
Aplicar el cambio introducido por el compromiso en la punta de la rama maestra y crear un
nuevo compromiso con este cambio.

git cherry-pick ..master, git cherry-pick ^ HEAD master
Aplicar los cambios introducidos por todas las confirmaciones que son ancestros del maestro pero no del
HEAD para producir nuevas confirmaciones.

git cherry-pick maint next ^ master, git cherry-pick maint master..next
Aplicar los cambios introducidos por todos los commits que son ancestros de maint o next, pero
ni amo ni ninguno de sus antepasados. Tenga en cuenta que esto último no significa mantenimiento y
todo entre el maestro y el siguiente; Específicamente, maint no se utilizará si es
incluido en master.

git cherry-pick master ~ 4 master ~ 2
Aplicar 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 siguiente
Aplicar al árbol de trabajo y al índice los cambios introducidos por el penúltimo
commit apuntado por master y por el último commit apuntado por next, pero no
cree cualquier compromiso con estos cambios.

git cherry-pick --ff .. siguiente
Si la historia 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
aquellas confirmaciones que están en el siguiente pero no HEAD a la rama actual, creando una nueva
comprometerse para cada nuevo cambio.

git rev-list --reverse master - README | git cherry-pick -n --stdin
Aplicar los cambios introducidos por todas las confirmaciones en la rama maestra que tocó README
al árbol de trabajo y al índice, por lo que el resultado se puede inspeccionar y convertir en un solo
nuevo compromiso si es adecuado.

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

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

1. aplique el cambio que mostraría git show topic ^. En este ejemplo, el parche
no se aplica claramente, por lo que la información sobre el conflicto se escribe en el índice y
árbol de trabajo y no hay 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 de cerezas, conservando
cualquier modificación local que haya tenido en el árbol de trabajo.
4. intente aplicar el cambio introducido por tema ^ nuevamente, dedicando más tiempo para evitar
errores basados ​​en líneas de contexto que coinciden incorrectamente.

Use git-cherry-pick en línea usando los servicios de onworks.net