git-rebase: en línea en la nube

PROGRAMA:

NOMBRE

git-rebase: el puerto de avance local se compromete con el encabezado ascendente actualizado

SINOPSIS

git rebase [-i | --interactive] [opciones] [--exec ] [--sobre ]
[ [ ]]
git rebase [-i | --interactive] [opciones] [--exec ] [--sobre ]
--raíz [ ]
git rebase --continuar | --skip | --aborto | --editar-todo

DESCRIPCIÓN

Si está especificado, git rebase realizará un pago automático de git
antes de hacer cualquier otra cosa. De lo contrario, permanece en la rama actual.

Si no se especifica, el upstream configurado en rama. .remote y
rama. Se utilizarán las opciones .merge (ver git-config(1) para obtener más detalles) y
Se asume la opción --fork-point. Si actualmente no se encuentra en ninguna sucursal o si el actual
rama no tiene un upstream configurado, la rebase abortará.

Todos los cambios realizados por confirmaciones en la rama actual pero que no están en son salvados
a un área temporal. Este es el mismo conjunto de confirmaciones que mostraría git log
..CABEZA; o por git log 'fork_point' .. HEAD, si --fork-point está activo (ver el
descripción en --punto de horquilla a continuación); o por git log HEAD, si se especifica la opción --root.

La rama actual se restablece a , o si se proporcionó la opción --onto.
Esto tiene exactamente el mismo efecto que git reset --hard (o ). ORIG_HEAD es
establecido para apuntar a la punta de la rama antes del reinicio.

Las confirmaciones que se guardaron previamente en el área temporal se vuelven a aplicar al
rama actual, una a una, en orden. Tenga en cuenta que cualquier confirmación en HEAD que introduzca la
mismos cambios textuales que una confirmación en HEAD .. se omiten (es decir, un parche ya
aceptado en sentido ascendente con un mensaje de confirmación diferente o se omitirá la marca de tiempo).

Es posible que un error de fusión impida que este proceso se complete por completo.
automático. Tendrá que resolver cualquier error de fusión de este tipo y ejecutar git rebase --continuar.
Otra opción es omitir la confirmación que causó el error de fusión con git rebase
--saltar. Para ver el original y elimine los archivos de trabajo .git / rebase-apply,
use el comando git rebase --abort en su lugar.

Suponga que existe el siguiente historial y que la rama actual es "tema":

Tema A --- B --- C
/
D --- E --- F --- G maestro

A partir de este punto, el resultado de cualquiera de los siguientes comandos:

maestro de git rebase
tema maestro de git rebase

sería:

Tema A '- B' - C '
/
D --- E --- F --- G maestro

NOTA: La última forma es solo una abreviatura del tema de git checkout seguido de git rebase
Maestro. Cuando rebase sale, el tema seguirá siendo la rama extraída.

Si la rama ascendente ya contiene un cambio que ha realizado (por ejemplo, porque envió un
parche que se aplicó en sentido ascendente), entonces se omitirá esa confirmación. Por ejemplo, corriendo
git rebase master en el siguiente historial (en el que A 'y A introducen el mismo conjunto de
cambios, pero tienen información de confirmación diferente):

Tema A --- B --- C
/
D --- E --- A '--- F maestro

resultará en:

Tema B '--- C'
/
D --- E --- A '--- F maestro

Así es como trasplantaría una rama temática basada en una rama a otra, para fingir
que bifurcó la rama de tema de la última rama, usando rebase --onto.

Primero asumamos tu tema se basa en la rama Next. Por ejemplo, una característica desarrollada en
tema depende de alguna funcionalidad que se encuentra en Next.

o --- o --- o --- o --- o maestro

o --- o --- o --- o --- o siguiente

o --- o --- o tema

Queremos hacer tema bifurcado de la rama dominar; por ejemplo, porque la funcionalidad en
lo cual tema Depende se fusionó en el más estable dominar rama. Queremos que nuestro árbol
se parece a esto:

o --- o --- o --- o --- o maestro
|
| o '- o' - o 'tema

o --- o --- o --- o --- o siguiente

Podemos obtener esto usando el siguiente comando:

git rebase --en el maestro siguiente tema

Otro ejemplo de la opción --onto es reajustar parte de una rama. Si tenemos lo siguiente
situación:

H --- I --- J temaB
/
E --- F --- G temaA
/
A --- B --- C --- D maestro

entonces el comando

git rebase --en el tema principalA topicB

resultaría en:

H '- I' - J 'tema B
/
| E --- F --- G temaA
|/
A --- B --- C --- D maestro

Esto es útil cuando el tema B no depende del tema A.

También se pueden eliminar varias confirmaciones con rebase. Si tenemos la siguiente situación:

E --- F --- G --- H --- I --- J temaA

entonces el comando

git rebase --en el temaA ~ 5 temaA ~ 3 temaA

resultaría en la eliminación de las confirmaciones F y G:

E --- H '--- I' --- J 'tema A

Esto es útil si F y G tienen algún defecto o no deberían ser parte del tema A. Nota
que el argumento a --onto y el El parámetro puede ser cualquier confirmación válida.

En caso de conflicto, git rebase se detendrá en el primer compromiso problemático y se irá
marcadores de conflicto en el árbol. Puedes usar git diff para localizar los marcadores (<<<<<<) y hacer
ediciones para resolver el conflicto. Para cada archivo que edite, debe decirle a Git que el
El conflicto se ha resuelto, normalmente esto se haría con

git agregar

Después de resolver el conflicto manualmente y actualizar el índice con la resolución deseada,
puede continuar el proceso de rebase con

git rebase --continuar

Alternativamente, puede deshacer el git rebase con

git rebase --abortar

CONFIGURACIÓN

rebase.stat
Ya sea para mostrar un diffstat de lo que cambió en sentido ascendente desde el último rebase. Falso por
predeterminada.

rebase.autoSquash
Si se establece en verdadero, habilite --autosquash opción por defecto.

rebase.autoStash
Si se establece en verdadero, habilite --autostash opción por defecto.

rebase.missingCommitsCheck
Si se establece en "advertir", imprime advertencias sobre confirmaciones eliminadas en modo interactivo. Si se establece en
"error", imprima las advertencias y detenga el rebase. Si se establece en "ignorar", no se verifica
hecho. "ignorar" por defecto.

formato de instrucción rebase.
Formato de lista de compromiso personalizado para usar durante una --interactivo rebase.

OPCIONES

--sobre
Punto de partida en el que crear las nuevas confirmaciones. Si la opción --onto no es
especificado, el punto de partida es . Puede ser cualquier compromiso válido, y no solo un
nombre de la rama existente.

Como caso especial, puede utilizar "A ... B" como atajo para la base de combinación de A y B si
hay exactamente una base de fusión. Puede omitir como máximo uno de A y B, en el que
caso de que por defecto sea HEAD.


Ramificación aguas arriba para comparar. Puede ser cualquier confirmación válida, no solo una existente
nombre de la sucursal. De forma predeterminada, se configura en sentido ascendente para la rama actual.


Rama de trabajo; por defecto es HEAD.

--Seguir
Reinicie el proceso de reajuste después de haber resuelto un conflicto de fusión.

--abortar
Abortar la operación de rebase y restablecer HEAD a la rama original. Si era
proporcionado cuando se inició la operación de rebase, HEAD se restablecerá a .
De lo contrario, HEAD se restablecerá a donde estaba cuando se inició la operación de rebase.

--mantener vacío
Mantenga las confirmaciones que no cambian nada de sus padres en el resultado.

--saltar
Reinicie el proceso de reajuste omitiendo el parche actual.

--editar-todo
Edite la lista de tareas pendientes durante un rebase interactivo.

-m, - fusionar
Utilice estrategias de fusión para reajustar. Cuando se utiliza la estrategia de fusión recursiva (predeterminada),
esto permite que rebase sea consciente de los cambios de nombre en el lado ascendente.

Tenga en cuenta que una fusión de rebase funciona al reproducir cada confirmación de la rama de trabajo en la parte superior
de El rama. Debido a esto, cuando ocurre un conflicto de fusión, el lado
reportado como soportar es la serie hasta ahora renovada, comenzando con , y suyo is
la rama de trabajo. En otras palabras, los lados se intercambian.

-s , --strategy =
Utilice la estrategia de fusión dada. Si no hay opción -s git fusionar-recursivo se utiliza
en lugar de. Esto implica - fusionar.

Gracias git rebase reproduce cada confirmación de la rama de trabajo en la parte superior de la
rama usando la estrategia dada, usando el soportar estrategia simplemente descarta
todos los parches del , lo que tiene poco sentido.

-X , --strategy-option =
Pasa el hasta la estrategia de fusión. Esto implica --merge y, si
no se ha especificado ninguna estrategia, -s recursive. Nótese la reversión de soportar y suyo as
mencionado anteriormente para la opción -m.

-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.

-q, - silencioso
Tranquilizarse. Implica --no-stat.

-v, --detallado
Sea prolijo. Implica --stat.

--estat
Muestre un diffstat de lo que cambió en sentido ascendente desde el último rebase. El diffstat también es
controlado por la opción de configuración rebase.stat.

-n, --no-estado
No muestre un diffstat como parte del proceso de rebase.

--no-verificar
Esta opción omite el gancho previo al rebase. Ver también garfios(5).

--verificar
Permite que se ejecute el gancho de pre-rebase, que es el valor predeterminado. Esta opción se puede utilizar para
anular --no-verificar. Ver también garfios(5).

-C
Asegúrese de al menos las líneas del contexto circundante coinciden antes y después de cada cambio.
Cuando existen menos líneas de contexto circundante, todas deben coincidir. Por defecto no
el contexto siempre se ignora.

-f, --force-rebase
Forzar un rebase incluso si la rama actual está actualizada y el comando sin
La fuerza volvería sin hacer nada.

Puede encontrar esto (o --no-ff con una rebase interactiva) útil después de revertir un
fusión de rama de tema, ya que esta opción recrea la rama de tema con nuevas confirmaciones, por lo que
se puede volver a fusionar con éxito sin necesidad de "revertir la reversión" (consulte la
revertir una fusión defectuosa Cómo Usar[1] para más detalles).

--punta de horquilla, --no-punta de horquilla
Utilice reflog para encontrar un mejor ancestro común entre y cuando
calcular qué confirmaciones han sido introducidas por .

Cuando --fork-point está activo, punto_horquilla se utilizará en lugar de para
calcular el conjunto de confirmaciones para rebase, donde punto_horquilla es el resultado de git
merge-base --fork-point comando (ver git-merge-base(1)). Si
punto_horquilla termina estando vacío, el se utilizará como alternativa.

Si alguno o --root se da en la línea de comando, entonces el valor predeterminado es
--no-fork-point, de lo contrario, el valor predeterminado es --fork-point.

--ignore-whitespace, --whitespace =
Estas banderas se pasan al git aplicar programa (ver aplicar git(1)) que aplica el
parche. Incompatible con la opción --interactive.

--fecha-committer-es-fecha-autor, --ignore-fecha
Estas banderas se pasan a git am para cambiar fácilmente las fechas de las confirmaciones rebasadas
(consulta: git-am(1)). Incompatible con la opción --interactive.

-i, --interactivo
Haga una lista de las confirmaciones que están a punto de volver a basarse. Deje que el usuario edite esa lista
antes de rebasar. Este modo también se puede utilizar para dividir confirmaciones (consulte DIVISIÓN DE COMPROMISOS
abajo).

El formato de la lista de confirmaciones se puede cambiar configurando la opción de configuración
rebase.instructionFormat. Un formato de instrucción personalizado tendrá automáticamente la
hash de confirmación largo antepuesto al formato.

-p, --preservar-fusionar
Recrear confirmaciones de fusión en lugar de aplanar el historial reproduciendo confirmaciones de fusión
commit introduce. Fusionar resoluciones de conflictos o enmiendas manuales para fusionar confirmaciones
no se conservan.

Esto utiliza la maquinaria interactiva internamente, pero combinándola con la
La opción interactiva explícitamente no es generalmente una buena idea a menos que sepa lo que
están haciendo (ver ERRORES a continuación).

-X , --exec
Agregar "ejecutivo "después de cada línea creando un compromiso en el historial final. voluntad
ser interpretado como uno o más comandos de shell.

Esta opción solo se puede usar con la opción --interactive (ver MODO INTERACTIVO
abajo).

Puede ejecutar varios comandos utilizando una instancia de --exec con varios
comandos:

git rebase -i --exec "cmd1 && cmd2 && ..."

o dando más de un --exec:

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

Si se usa --autosquash, no se agregarán líneas "exec" para el intermedio
se confirma, y ​​solo aparecerá al final de cada serie de squash / fixup.

--raíz
Rebase todas las confirmaciones accesibles desde , en lugar de limitarlos con un
. Esto le permite reajustar la (s) confirmación (es) raíz en una rama. Cuando se usa con
--onto, omitirá los cambios ya contenidos en (en lugar de )
mientras que sin --onto operará en cada cambio. Cuando se usa junto con ambos
--onto y --preserve-fusiona, todos las confirmaciones de root se reescribirán para tener como
padre en su lugar.

--autosquash, --no-autosquash
Cuando el mensaje de registro de confirmación comienza con "squash! ..." (o "fixup! ..."), y hay
una confirmación cuyo título comienza con el mismo ..., modifica automáticamente la lista de tareas de
rebase -i de modo que la confirmación marcada para aplastar viene justo después de la confirmación para ser
modificado, y cambie la acción de la confirmación movida de recoger a aplastar (o arreglar).
Ignora los siguientes "arreglos" o "¡aplasta!" Después del primero, en caso de que se refiera a un
reparación / squash anterior con git commit --fixup / - squash.

Esta opción solo es válida cuando el --interactivo se utiliza la opción.

Si --autosquash La opción está habilitada por defecto usando la variable de configuración
rebase.autoSquash, esta opción se puede utilizar para anular y deshabilitar esta configuración.

--autostash, --no-autostash
Cree automáticamente un alijo temporal antes de que comience la operación y aplíquelo después
finaliza la operación. Esto significa que puede ejecutar rebase en un árbol de trabajo sucio. Sin embargo,
Úselo con cuidado: la aplicación de alijo final después de un rebase exitoso puede resultar en
conflictos no triviales.

--no-ff
Con --interactive, seleccione todas las confirmaciones rebasadas en lugar de adelantarlas rápidamente.
los que no han cambiado. Esto asegura que todo el historial de la rama rebasada sea
compuesto por nuevas confirmaciones.

Sin --interactive, esto es sinónimo de --force-rebase.

Puede encontrar esto útil después de revertir una combinación de rama de tema, ya que esta opción
recrea la rama del tema con nuevas confirmaciones para que pueda volver a fusionarse con éxito
sin necesidad de "revertir la reversión" (ver el revertir una fusión defectuosa Cómo Usar[1] para
detalles).

UNIR ESTRATEGIAS

El mecanismo de combinación (comandos git merge y git pull) permite que el backend unir estrategias
a elegir con la opción -s. Algunas estrategias también pueden tomar sus propias opciones, que pueden ser
pasado dando -X argumentos para git merge y / o git pull.

Resolvemos
Esto solo puede resolver dos cabezas (es decir, la rama actual y otra rama que extrajo
from) utilizando un algoritmo de combinación de 3 vías. Intenta detectar cuidadosamente la fusión entrecruzada
ambigüedades y se considera generalmente seguro y rápido.

recursiva
Esto solo puede resolver dos cabezas usando un algoritmo de combinación de 3 vías. Cuando hay mas de
un antepasado común que se puede utilizar para la fusión de 3 vías, crea un árbol fusionado de la
ancestros comunes y lo usa como árbol de referencia para la combinación de 3 vías. Esto tiene
Se ha informado que da como resultado menos conflictos de fusión sin causar fusiones erróneas en las pruebas.
realizado en confirmaciones de fusión reales tomadas del historial de desarrollo del kernel de Linux 2.6.
Además, esto puede detectar y manejar fusiones que implican cambios de nombre. Este es el predeterminado
fusionar estrategia al extraer o fusionar una rama.

La recursiva La estrategia puede tomar las siguientes opciones:

soportar
Esta opción obliga a que los trozos en conflicto se resuelvan automáticamente de forma limpia al favorecer nuestro
versión. Los cambios del otro árbol que no entran en conflicto con nuestro lado son
reflejado en el resultado de la fusión. Para un archivo binario, se toman todos los contenidos
de nuestro lado.

Esto no debe confundirse con el soportar fusionar estrategia, que ni siquiera parece
en lo que el otro árbol contiene en absoluto. Descarta todo lo que hizo el otro árbol,
declarando nuestro la historia contiene todo lo que sucedió en ella.

suyo
Esto es lo contrario de soportar.

paciencia
Con esta opción fusionar-recursivo dedica un poco más de tiempo para evitar combinaciones erróneas
que a veces ocurren debido a líneas coincidentes sin importancia (p. ej., llaves de distintas
funciones). Úselo cuando las ramas que se van a fusionar hayan divergido enormemente. Ver también
diferencia git(1) --paciencia.

algoritmo diff = [paciencia | mínimo | histograma | myers]
Informa fusionar-recursivo utilizar un algoritmo de diferencia diferente, que puede ayudar a evitar
combinaciones erróneas que ocurren debido a líneas coincidentes sin importancia (como llaves de
funciones distintas). Ver también diferencia git(1) - algoritmo de diferencia.

ignorar-espacio-cambio, ignorar-todo-espacio, ignorar-espacio-en-eol
Trata las líneas con el tipo de cambio de espacio en blanco indicado como sin cambios para el
en aras de una fusión de tres vías. Cambios de espacios en blanco mezclados con otros cambios en una línea
no se ignoran. Ver también diferencia git(1) -b, -w y --ignore-space-at-eol.

· Si su la versión solo introduce cambios de espacios en blanco en una línea, nuestro la versión es
usado;

· Si nuestro la versión introduce cambios en los espacios en blanco pero su la versión incluye un
cambio sustancial, su se utiliza la versión;

· De lo contrario, la fusión se realiza de la forma habitual.

renormalizar
Esto ejecuta un check-out y check-in virtual de las tres etapas de un archivo cuando
resolver una combinación de tres vías. Esta opción está destinada a utilizarse al fusionar ramas.
con diferentes filtros limpios o reglas de normalización de final de línea. Ver "Fusionar
sucursales con diferentes atributos de registro / salida "en atributos de git(5) para
Detalles.

no renormalizar
Desactiva la opción de renormalizar. Esto anula merge.renormalize
variable de configuración.

renombrar-umbral =
Controla el umbral de similitud utilizado para la detección de cambio de nombre. Ver también diferencia git(1)
-METRO.

subárbol [= ]
Esta opción es una forma más avanzada de subárbol estrategia, donde la estrategia hace
una suposición sobre cómo se deben cambiar dos árboles para que coincidan al fusionarse.
En cambio, la ruta especificada tiene un prefijo (o se elimina desde el principio) para hacer
la forma de dos árboles a juego.

pulpo
Esto resuelve casos con más de dos cabezas, pero se niega a hacer una combinación compleja que
necesita resolución manual. Está destinado principalmente a ser utilizado para agrupar ramas de temas.
cabezas juntas. Esta es la estrategia de fusión predeterminada cuando se extrae o fusiona más de
una rama.

soportar
Esto resuelve cualquier número de cabezas, pero el árbol resultante de la fusión es siempre ese
de la rama actual, ignorando efectivamente todos los cambios de todas las demás ramas.
Está destinado a reemplazar el antiguo historial de desarrollo de las ramas laterales. Nota
que esto es diferente de la opción -Xours a la recursiva fusionar estrategia.

subárbol
Esta es una estrategia recursiva modificada. Al fusionar los árboles A y B, si B corresponde a
un subárbol de A, B se ajusta primero para que coincida con la estructura de árbol de A, en lugar de
leyendo los árboles al mismo nivel. Este ajuste también se realiza al común
árbol ancestro.

Con las estrategias que utilizan la combinación de 3 vías (incluida la predeterminada, recursiva), si hay un cambio
se realiza en ambas ramas, pero luego se revierte en una de las ramas, ese cambio será
presente en el resultado combinado; algunas personas encuentran confuso este comportamiento. Ocurre porque
Cuando se realiza una combinación, solo se consideran las cabezas y la base de combinación, no las
confirmaciones individuales. Por lo tanto, el algoritmo de fusión considera el cambio revertido como no
cambiar en absoluto, y sustituye la versión modificada en su lugar.

NOTAS

Debe comprender las implicaciones de usar git rebase en un repositorio que compartes.
Consulte también RECUPERACIÓN DE LA REFUERZO ARRIBA a continuación.

Cuando se ejecuta el comando git-rebase, primero ejecutará un gancho "pre-rebase" si uno
existe. Puede utilizar este gancho para realizar comprobaciones de cordura y rechazar la rebase si no lo es.
apropiado. Consulte la secuencia de comandos de enlace de pre-rebase de la plantilla para ver un ejemplo.

Al finalizar, será la rama actual.

INTERACTIVO MODO

Rebasar de forma interactiva significa que tienes la oportunidad de editar las confirmaciones que se vuelven a basar.
Puede reordenar las confirmaciones y puede eliminarlas (eliminando malas o de otra manera
parches no deseados).

El modo interactivo está diseñado para este tipo de flujo de trabajo:

1. tienes una idea maravillosa

2. piratear el código

3. preparar una serie para su presentación

4. enviar

donde el punto 2. consta de varias instancias de

a) uso regular

1. Termina algo digno de un compromiso

2. comprometerse

b) reparación independiente

1. darse cuenta de que algo no funciona

2. arregla eso

3. cometerlo

A veces lo arreglado en b.2. no se puede modificar para que no sea del todo perfecto, cometerlo
arreglos, porque esa confirmación está profundamente enterrada en una serie de parches. Eso es exactamente lo que
La rebase interactiva es para: úselo después de muchas "a" y "b", reorganizando y
editar confirmaciones y aplastar varias confirmaciones en una.

Comience con la última confirmación que desea conservar como está:

git rebase -i

Se activará un editor con todas las confirmaciones en su rama actual (ignorando la combinación
commits), que vienen después del commit dado. Puede reordenar las confirmaciones en esta lista para
el contenido de su corazón, y puede eliminarlos. La lista se parece más o menos a esto:

elegir deadbee La línea de este compromiso
pick fa1afe1 La línea de la próxima confirmación
...

Las descripciones en línea son puramente para su placer; git rebase no los miraré
pero en los nombres de las confirmaciones ("deadbee" y "fa1afe1" en este ejemplo), así que no elimines ni
editar los nombres.

Si reemplaza el comando "seleccionar" por el comando "editar", puede saber git rebase para detener
después de aplicar esa confirmación, para que pueda editar los archivos y / o el mensaje de confirmación,
modifique el compromiso y continúe reajustando.

Si solo desea editar el mensaje de confirmación para una confirmación, reemplace el comando "seleccionar" con
el comando "reformular".

Para eliminar una confirmación, reemplace el comando "seleccionar" con "soltar", o simplemente elimine la coincidencia
la línea.

Si desea plegar dos o más confirmaciones en una, reemplace el comando "seleccionar" por el
segundo y subsiguientes confirmaciones con "squash" o "fixup". Si las confirmaciones tuvieran diferentes
autores, la confirmación doblada se atribuirá al autor de la primera confirmación. los
mensaje de confirmación sugerido para la confirmación plegada es la concatenación de los mensajes de confirmación
de la primera confirmación y de aquellos con el comando "squash", pero omite los mensajes de confirmación
de confirmaciones con el comando "fixup".

git rebase se detendrá cuando "seleccionar" haya sido reemplazado por "editar" o cuando un comando falle debido
para fusionar errores. Cuando haya terminado de editar y / o resolver conflictos, puede continuar
con git rebase --continuar.

Por ejemplo, si desea reordenar las últimas 5 confirmaciones, de modo que lo que era HEAD ~ 4 se convierta en
la nueva CABEZA. Para lograr eso, llamarías git rebase Me gusta esto:

$ git rebase -i HEAD ~ 5

Y mueva el primer parche al final de la lista.

Es posible que desee conservar las fusiones, si tiene un historial como este:

X

A --- M --- B
/
--- o --- O --- P --- Q

Suponga que desea volver a ajustar la base de la rama lateral desde "A" hasta "Q". Asegúrese de que el
HEAD actual es "B", y llame

$ git rebase -i -p --onto QO

Reordenar y editar confirmaciones generalmente crea pasos intermedios no probados. Es posible que desee
para verificar que la edición de su historial no rompió nada al ejecutar una prueba, o al menos
recompilar en puntos intermedios del historial usando el comando "exec" (atajo "x").
Puede hacerlo creando una lista de tareas como esta:

elegir deadbee Implementar la función XXX
fixup f1a5c00 Arreglar para presentar XXX
marca ejecutiva
pick c0ffeee La línea de la próxima confirmación
editar deadbab La línea de la confirmación después
subdirectorio exec cd; hacer prueba
...

La rebase interactiva se detendrá cuando un comando falla (es decir, sale con un estado distinto de 0) para
darle la oportunidad de solucionar el problema. Puede continuar con git rebase --continuar.

El comando "exec" lanza el comando en un shell (el especificado en $ SHELL, o el
shell predeterminado si $ SHELL no está configurado), por lo que puede usar funciones de shell (como "cd", ">", ";"
...). El comando se ejecuta desde la raíz del árbol de trabajo.

$ git rebase -i --exec "hacer prueba"

Este comando le permite verificar que las confirmaciones intermedias sean compilables. La lista de cosas por hacer
se vuelve así:

elige 5928aea uno
ejecutivo hacer prueba
elegir 04d0fda dos
ejecutivo hacer prueba
elegir ba46169 tres
ejecutivo hacer prueba
elegir f4593f9 cuatro
ejecutivo hacer prueba

TERRIBLE COMPROMISOS

En modo interactivo, puede marcar confirmaciones con la acción "editar". Sin embargo, esto no
necesariamente significa que git rebase espera que el resultado de esta edición sea exactamente una confirmación.
De hecho, puede deshacer la confirmación o puede agregar otras confirmaciones. Esto se puede utilizar para dividir un
comprometerse en dos:

· Inicie una rebase interactiva con git rebase -i ^, donde es el compromiso
quieres dividir. De hecho, cualquier rango de confirmación servirá, siempre que contenga eso
cometer.

· Marque la confirmación que desea dividir con la acción "editar".

· Cuando se trata de editar esa confirmación, ejecute git reset HEAD ^. El efecto es que el
HEAD se rebobina en uno y el índice sigue su ejemplo. Sin embargo, el árbol de trabajo permanece
lo mismo.

· Ahora agregue los cambios al índice que desea tener en la primera confirmación. Usted puede
use git add (posiblemente de forma interactiva) o git gui (o ambos) para hacer eso.

· Confirme el índice actual con cualquier mensaje de confirmación que sea apropiado ahora.

· Repita los dos últimos pasos hasta que su árbol de trabajo esté limpio.

· Continúe la rebase con git rebase --continúe.

Si no está absolutamente seguro de que las revisiones intermedias sean coherentes (
compilar, pasar el conjunto de pruebas, etc.) debe usar git alijo para esconder el
cambios aún no confirmados después de cada confirmación, prueba y modificación de la confirmación si se han corregido
necesario.

RECUPERACIÓN DESDE RÍO ARRIBA REBAJAR

Rebasar (o cualquier otra forma de reescribir) una rama en la que otros han basado el trabajo es un mal
idea: cualquiera que esté aguas abajo se ve obligado a corregir manualmente su historial. Esta sección
explica cómo hacer la corrección desde el punto de vista del downstream. La verdadera solución, sin embargo,
sería evitar rebasar el upstream en primer lugar.

Para ilustrarlo, suponga que se encuentra en una situación en la que alguien desarrolla una subsistema rama,
y estás trabajando en un tema que depende de esto subsistema. Podrías terminar con
una historia como la siguiente:

o --- o --- o --- o --- o --- o --- o --- o --- o maestro

o --- o --- o --- o --- o subsistema

*---*---* tema

If subsistema se basa en dominar, sucede lo siguiente:

o --- o --- o --- o --- o --- o --- o --- o maestro
\
o --- o --- o --- o --- o o '- o' - o '- o' - o 'subsistema

*---*---* tema

Si ahora continúa con el desarrollo como de costumbre y, finalmente, se fusiona tema a subsistema,
se compromete desde subsistema permanecerá duplicado para siempre:

o --- o --- o --- o --- o --- o --- o --- o maestro
\
o --- o --- o --- o --- o o '- o' - o '- o' - o '- Subsistema M
\ /
*---*---*-..........-*--* tema

Estos duplicados generalmente están mal vistos porque desordenan la historia, lo que hace que
más difícil de seguir. Para limpiar las cosas, debes trasplantar las confirmaciones en tema En el correo electrónico “Su Cuenta de Usuario en su Nuevo Sistema XNUMXCX”.
new subsistema propina, es decir, rebase tema. Esto se convierte en un efecto dominó: cualquiera que esté aguas abajo
Desde tema se ve obligado a rebasar también, ¡y así sucesivamente!

Hay dos tipos de correcciones, que se analizan en las siguientes subsecciones:

Caso fácil: los cambios son literalmente los mismos.
Esto sucede si el subsistema rebase fue un rebase simple y no tuvo conflictos.

Estuche rígido: los cambios no son los mismos.
Esto sucede si el subsistema rebase tuvo conflictos, o usó --interactive para omitir,
editar, aplastar o arreglar confirmaciones; o si el upstream usó uno de commit --amend, reset,
o rama de filtro.

La de forma sencilla case
Solo funciona si los cambios (ID de parche basados ​​en el contenido de la diferencia) en subsistema están
literalmente lo mismo antes y después del rebase subsistema hice.

En ese caso, la solución es fácil porque git rebase sabe omitir los cambios que ya están
presente en el nuevo upstream. Entonces, si dices (asumiendo que estás en tema)

$ git rebase subsistema

terminarás con el historial fijo

o --- o --- o --- o --- o --- o --- o --- o maestro

o '- o' - o '- o' - o 'subsistema

*---*---* tema

La en las case
Las cosas se complican si el subsistema los cambios no corresponden exactamente a los
antes del rebase.

Nota
Si bien una "recuperación de caso fácil" a veces parece tener éxito incluso en los
caso, puede tener consecuencias no deseadas. Por ejemplo, una confirmación que se eliminó a través de
git rebase - interactivo será resucitado!

La idea es contar manualmente git rebase "donde el viejo subsistema terminó y tu tema
comenzó ", es decir, cuál era la antigua base de fusión entre ellos. Tendrá que encontrar una manera de
nombrar el último compromiso del viejo subsistema, Por ejemplo:

· Con el subsistema reflog: después git ha podido recuperar, el viejo consejo de subsistema Está en
subsistema @ {1}. Las recuperaciones posteriores aumentarán el número. (Ver git-reflog(1).)

· Relativo a la punta de tema: sabiendo que tu tema tiene tres confirmaciones, el viejo consejo
of subsistema debe ser el tema ~ 3.

A continuación, puede trasplantar el antiguo subsistema .. tema al nuevo consejo diciendo (para el reflog
caso, y asumiendo que estás en tema ya):

$ git rebase --en el subsistema del subsistema @ {1}

El efecto dominó de una recuperación de "caso duro" es especialmente malo: todos aguas abajo de
tema ahora también tendrá que realizar una recuperación de "caso duro".

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