Olvidé "git rebase --continue" e hice "git commit". ¿Como arreglar?

112

Estaba cambiando el código en git, tuve algunos conflictos de fusión. Resolví los conflictos e hice:

git add

En este punto me olvidé de hacer:

git rebase --continue

Seguí codificando e hice:

git commit

por los cambios. Ahora estoy encendido "no branch"y no puedo hacer:

git rebase --continue

¿Cómo puedo solucionar esto?

git

— Abhilash
fuente

# Actualmente no en ninguna sucursal. nada que confirmar (directorio de trabajo limpio)

— Abhilash

5

EDITAR : Mire la respuesta a continuación también para ver si esa es una solución más fácil para usted. https://stackoverflow.com/a/12163247/493106

Tendría que probarlo, pero creo que esto es lo que haría:

Etiquete su última confirmación (o simplemente escriba su SHA1 en algún lugar para no perderlo): git tag temp
git rebase --abort
Haz el rebase de nuevo. Tendrá que resolver la fusión nuevamente. :(
git rebase --continue
git cherry-pick temp

El problema con esto es que su tempconfirmación probablemente contenga tanto la resolución de la fusión como el nuevo código. Así que podría ser complicado, pero lo probaría y vería si funciona.

— MatrixFrog
fuente

O puede etiquetar como dice @MatrixFrog o también puede guardarlo como un parche. Luego, aborta el rebase. Verifique el estado para asegurarse de que el repositorio esté en un estado en el que sepa que no tuvo problemas y luego inicie la recuperación y el rebase.

— yasouser

17

No hagas esto. Vea la respuesta de kirikaza a continuación para una manera mucho más simple / limpia. No se meta con la selección selectiva y la resolución de conflictos por segunda vez.

— tandrewnichols

4

@Abhilash Por favor acepte la respuesta de kirikaza. Yo (al igual que tandrewnichols) hice esto y había una manera mucho más fácil (e Internet parece estar de acuerdo, ya que esa respuesta tiene 4 veces los votos a favor).

— David Doria

Ahora son 10 veces los votos a favor ... también, use git rerere para recordar las resoluciones de sus conflictos (útil, a menos que a veces tome malas resoluciones que no quiera que recuerde).

— Ajax

216

Solo hazlo git reset --soft HEAD^. Mueve el puntero HEAD a su padre, pero mantiene el árbol de trabajo y agrega el cambio de combinación al índice. Para que pueda continuar reajustando git rebase --continuecomo antes.

— kirikaza
fuente

1

Esto funcionó totalmente, y también fue la primera vez que encontré un uso para --soft. ¡Es bueno saber cómo funciona, gracias!

— mmocny

1

¡Espero que la gente vea todos los votos a favor de esta respuesta y siga lo que se sugiere aquí!

— Raghu

1

Esto es exactamente lo que pensé (pero puede que haya pasado con dificultad por accidente). Sin embargo, no estaba seguro de si HEAD se estaba actualizando durante una rebase. ¡Gracias por confirmar! Me alegro de haber avanzado un poco más antes de jugar con el dolor de cabeza de arriba.

— DeezCashews

Edité la respuesta aceptada para poner un enlace aquí. No vi esta respuesta hasta que seguí las instrucciones anteriores.

— xaxxon

0

Tuve el mismo problema y, para empeorarlo, estaba reajustando tres confirmaciones y, después de resolver los conflictos en la segunda confirmación, "comprometí" en lugar de "reajustar - continuar".

Como resultado tuve este reflog de git

Cuando apliqué la solución de kirikaza, simplemente revirtí la tercera confirmación, y no la segunda, que era problemática.

Como puede ver, el rebase comienza con un checkout desde la rama remotes / origin / master y luego aplica mis tres confirmaciones que aparecen como las tres operaciones anteriores (antes del checkout) en el reflog.

Luego, si desea reiniciar desde una base limpia, antes de la rebase, simplemente puede restablecer el hash de forma completa justo antes de la comprobación de la operación de rebase. En mi caso (ver foto):

git reset --hard 859ed3c

Entonces puedes empezar de nuevo git rebase.

— Louis Durand
fuente

0

Tenía git rebased, solucioné conflictos, git agregó un archivo con conflictos y (por error) cometí.

Probé las soluciones git reset --soft HEAD^y git reset --harddadas, pero ninguna funcionó para mí.

Sin embargo, simplemente git rebase --abortfuncionó: me llevó a antes del inicio de la rebase con un árbol de trabajo limpio.

— retazo o restos
fuente