Git rebase: continúe con las quejas incluso cuando se hayan resuelto todos los conflictos de fusión

115

Estoy enfrentando un problema que no estoy seguro de cómo resolver.

Hice una rebase contra el maestro de mi rama:

git rebase master

y obtuve el siguiente error

 First, rewinding head to replay your work on top of it...
 Applying: checkstyled.
 Using index info to reconstruct a base tree...
 Falling back to patching base and 3-way merge...
 Auto-merging AssetsLoader.java
 CONFLICT (content): Merge conflict in AssetsLoader.java
 Failed to merge in the changes.
 Patch failed at 0001 checkstyled.

Así que fui a mi editor favorito, arreglé el conflicto de 1 línea, guardé el archivo e hice un estado de git y obtuve el siguiente resultado:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   PassengerContactHandler.java
 #
 # Unmerged paths:
 #   (use "git reset HEAD <file>..." to unstage)
 #   (use "git add/rm <file>..." as appropriate to mark resolution)
 #
 #  both modified:      AssetsLoader.java
 #

Hice un git add AssetsLoader.java y un estado de git y obtuve lo siguiente:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   AssetsLoader.java
 #  modified:   PassengerContactHandler.java
 #

y cuando hice git rebase, continúo obteniendo:

git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

Sé que puedo omitir el parche y continuar con la reorganización, pero no estoy seguro de si los cambios en PassengerContactHandler.java se reorganizarán en mi rama o no.

así que no estoy seguro, ¿cómo debo proceder?

Editar: ¿Podría ser que el archivo con el conflicto resuelto sea exactamente como la versión original?

Muchas gracias lucas

Editar, me acaba de pasar de nuevo:

Me acaba de pasar de nuevo

(307ac0d...)|REBASE)$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   assets/world/level1/Level-1.xml
#   modified:   George.java
#   modified:   DefaultPassenger.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   mb-art/originalAssets/27dec/

((307ac0d ...) | REBASE) $ git rebase --continuar

You must edit all merge conflicts and then
mark them as resolved using git add

git --version

git version 1.7.1

git rebase

— Lucas
fuente

Ese es el resultado completo de git status, ¿verdad? ¿No falta una sección debajo?

— Cascabel

git-rebaseNunca debe informar que hay conflictos sin resolver si no los hay. Si puede lograr reproducir el problema en un caso de prueba más simple, sería mucho más fácil de depurar, pero aún así, si no git statusinforma ningún conflicto cuando lo git rebase --continuehace, y su versión de Git es actual, puede intentar enviar un correo electrónico al desarrollador de Git. lista de correo en git@vger.kernel.org con toda la información de diagnóstico que pueda obtener.

— Cascabel

1

Me acaba de pasar de nuevo, (307ac0d ...) | REBASE) $ git status # Actualmente no en ninguna rama. # Cambios a confirmar: # (use "git reset HEAD <file> ..." para quitar la etapa) # # modificado: assets / world / level1 / Level-1.xml # modificado: George.java # modificado: DefaultPassenger.java # # Archivos sin seguimiento: # (use "git add <file> ..." para incluirlo en lo que se confirmará) # # mb-art / originalAssets / 27dec /

— Lucas

Creo que deberías usar GITKRAKEN, te ayudará a resolver tus conflictos.

— Nikhil Bhardwaj

115

Esto sucede porque al solucionar un conflicto, eliminó todo el código del parche que se estaba aplicando a la rama en la que está reajustando. Use git rebase --skippara continuar.

Un poco más de detalles:

Normalmente, cuando se soluciona un conflicto durante el rebase, editará el archivo en conflicto, manteniendo parte o todo el código del parche que se está aplicando actualmente a la rama en la que rebase. Después de arreglar el parche y hacer

git add your/conflicted/file
git status

obtendrá una línea (generalmente verde) que muestra el archivo modificado

modificado: su archivo / en conflicto

git rebase --continue funcionará bien en esta situación.

A veces, sin embargo, al resolver el conflicto, elimina todo en su nuevo parche, conservando solo el código de la rama en la que se basó. Ahora, cuando agregue el archivo, será exactamente como en el que intentó reajustar. git status no mostrará una línea verde que muestre los archivos modificados. Ahora, si lo haces

git rebase --continue

git se quejará con

Sin cambios, ¿olvidó usar 'git add'?

Lo que git realmente quiere que hagas en esta situación es usar

git rebase --skip

para omitir el parche. Anteriormente nunca hice esto, ya que siempre no estaba seguro de qué se omitiría si lo hiciera, no era obvio para mí lo que realmente significaba "omitir este parche". Pero si no obtienes una línea verde con

modificado: su archivo / en conflicto

después de editar el archivo en conflicto, agregarlo y hacer el estado de git, puede estar bastante seguro de que eliminó todo el parche y, en su lugar, puede usar

git rebase --skip

continuar.

La publicación original decía que esto a veces funciona:
git add -A
git rebase --continue
# works magically?

... pero no confíe en esto (y asegúrese de no agregar archivos sobrantes en las carpetas de su repositorio)

— jonasfh
fuente

1

Parecía tener el mismo problema y la misma solución, ¡también parecía mágico!

— bspink

Tuve el mismo problema, parece que si refactorizó en la rama rebasada y agregó nuevos archivos, y luego el proceso de resolución de fusión realizó cambios en esos nuevos archivos, debe agregarlos explícitamente de nuevo.

— Ibrahim

No hagas esto a menos que quieras rastrear todos los archivos basura en tu repositorio.

— Jed Lynch

git add ...se vuelve realmente molesto escribir después de cambiar un montón de archivos con rutas largas. ¿Hay un git add --all-the-files-i-changedque pueda ejecutar antes git rebase continue?

— jozxyqk

3

Tenga cuidado al usar el comando git rebase --skip, puede perder su trabajo (archivos editados)

— Youness Marhrani

21

Parece ser un error en Git 1.7

Aquí hay un buen artículo sobre cómo resolver esto .

Básicamente debería funcionar, si haces un

git diff

después de resolver sus conflictos y luego

git rebase --continue

Deberia trabajar.

— cumbre
fuente

8

Recibí esta advertencia cuando tenía archivos sin preparar. Asegúrese de no tener ningún archivo sin preparar. Si no desea que los archivos sin etapas cambien, descarte los cambios con

git rm <filename>

— ScottyBlades
fuente

2

Tan simple que podría ser un comentario; tan útil que debería ser una respuesta. ¡Gracias!

— Lucas Lima

4

Intente ejecutar esto en su línea de comando:

$ git mergetool

Debería abrir un editor interactivo que le permita resolver los conflictos. Más fácil que intentar hacerlo manualmente, y también git reconocerá cuando realice la combinación. También evitará situaciones en las que no se fusiona completamente por accidente, lo que puede ocurrir cuando intenta hacerlo manualmente.

— Batkins
fuente

Simplemente pensé que podría ser más fácil y también le permitiría evitar situaciones como esta en el futuro.

— Batkins

1

Salvaste mi noche. Aunque es una herramienta simple, nunca podría descubrir cómo resolver mis conflictos sin esta herramienta.

— eonil

4

Después de solucionar el conflicto, asegúrese de que los archivos modificados se agreguen a sus archivos almacenados. Esto resolvió mi problema.

— primulaveris
fuente

Esto funcionó para mí. Verifiqué Sourcetree después de recibir el mensaje descrito en el OP, e inmediatamente vi los dos archivos mencionados en la ventana de comandos allí como sin etapas. Organice los archivos, ejecuté "git rebase --continue" y volví a encaminarme.

— Mass Dot Net

3

Te perdiste un conflicto de fusión en AssetsLoader.java. Ábrelo y busca marcadores de conflicto (">>>>", "====", "<<<<<") y luego haz git add nuevamente. Haz un 'git diff --staged' si tienes dificultades para encontrarlo.

— Éter
fuente

3

Hice un grep en todos los archivos rastreados y no hubo marcadores de conflicto.

— Lucas

¿ git diff --stagedRevela algo útil? Esto indica qué cambios está a punto de realizar para resolver los conflictos de fusión en este punto del rebase. Debería haber un "Ups, eso no es lo que pretendía hacer para resolver este" bit en uno de los archivos.

— Ether

4

Git no busca marcadores de conflicto de fusión cuando intentas seguir adelante. Solo comprueba que el índice esté limpio. Si preparó un archivo que todavía tiene marcadores de conflicto, está indicando que desea confirmarlo con ellos. Probablemente siempre sea un error, pero te permitirá hacerlo.

— Cascabel

@Ether esta no es la razón en absoluto. Puede crear git addun archivo incluso con marcadores de conflicto. Después de todo, ¡estos archivos pueden ser perfectamente legales!

— fge

@Jefromi: a, ¡bueno saberlo! Siempre asumí que los marcadores estaban revisados, y uno tendría que pasarlos si era intencional.

— Ether

3

Acabo de tener este problema, y aunque creo que puede haber algunas causas, aquí está la mía ...

Tenía un gancho de confirmación previa de git que rechazaba las confirmaciones bajo ciertas condiciones. Esto está bien cuando se confirma manualmente, ya que mostrará la salida del gancho, y puedo arreglarlo o elegir ignorarlo usando commit --no-verify.

El problema parece ser que al rebasar, rebase --continue también llamará al gancho (para realizar la última serie de cambios). Pero rebase no mostrará la salida del gancho, solo verá que falló y luego escupirá un error menos específico que dice 'Debe editar todos los conflictos de fusión y luego marcarlos como resueltos usando git add'

Para solucionarlo, organice todos sus cambios y, en lugar de hacer 'git rebase --continue', intente un 'git commit'. Si sufre el mismo problema de gancho, debería ver las razones por las que falla.

Curiosamente, aunque git rebase no muestra la salida de git hook, acepta un --no-verify para omitir los hooks.

— carpii
fuente

1

Tuve un problema similar. Nada más aquí funcionó para mí, pero simplemente hacer 'git commit' y luego abortar pareció resolver mágicamente cualquier discrepancia que hubiera, y luego pude 'git rebase --continuar' con éxito.

— patrickvacek

Solo para que conste, ya que he estado luchando con un problema similar recientemente, git rebaseacepta la --no-verifyopción. Sin embargo, solo omite el pre-rebasegancho, pero esta opción no se aplica en las siguientes llamadas a git commit.

— pkrysiak

Contiene un punto válido (cambios de confirmación) pero demasiado detallado para una buena respuesta.

— Jack Miller

1

Acabo de tropezar con el problema. No lo haría git rebase --skip porque git statusmostraría claramente las modificaciones escalonadas, que quería mantener. Aunque tuve algunos archivos adicionales que llegaron inesperadamente. Resolví con

git checkout .

para eliminar las modificaciones no etiquetadas, luego git rebase --continuetuvo éxito.

— Ghislain
fuente

1

Una vez que haya corregido los cambios, es posible que olvide ejecutar 'git add -A'

git add -A
git rebase --continue

— gsalgadotoledo
fuente