Pregunta git rebase --continue no funcionará


yo si git rebase master, solucionó los conflictos informados en un archivo y luego git add el archivo para resolver el conflicto Entonces lo hice git rebase --continue, y obtuve esto:

Aplicando: Prueba de unidad fija

Sin cambios: ¿se olvidó de usar 'git   añadir'? Si no queda nada por hacer, es probable que algo   else ya introdujo los mismos cambios; es posible que desee omitir esto   parche.

Cuando hayas resuelto este problema, ejecuta "git rebase --continuar". Si   Si prefiere omitir este parche, ejecute "git rebase --skip" en su lugar. A   echa un vistazo a la rama original y deja de actualizar, ejecuta "git rebase"   --abortar".

¿Alguna idea de lo que me falta aquí? Debería hacer git rebase --skip?


32
2018-02-19 18:55


origen


Respuestas:


Si está en Mac OS X, primero debe desactivar revisiond, ya que puede interferir con los archivos en el árbol de trabajo en el medio de la rebase, lo que provoca un comportamiento impredecible y roto:

git config --global core.trustctime false

El problema se explica en Este artículoy muchas gracias a @nickfalk quien lo señaló

En cuanto a su rebase, este tipo de situación no es inusual en la práctica. Tratemos de pensar a través de los pasos de lo que está sucediendo:

  • Cuando restabas la rama actual en la parte superior de otra rama, git mueve la CABEZA a la otra rama y comienza a aplicar las confirmaciones únicas que tienes en tu rama actual.

  • Mientras reproduces uno de esos commits, llegaste a un conflicto. Lo resolvió, pero como resultado, no hay cambios para confirmar, nada para reproducir en este compromiso.

Prácticamente, esto significa que rechazaste los cambios en la confirmación actual que se está reproduciendo. Entonces, si no necesita nada de esta confirmación, es normal omitirla. Asi que git rebase --skip tiene sentido aquí.


25
2018-02-19 19:56



¡Aliento, no te estás volviendo loco! ; - = Este es un error conocido donde OSX (si eso es lo que estás usando) está jugando con git, se detalla aquí (no por mí).

La historia corta (es decir, la solución) es:

git config --global core.trustctime false

3
2018-02-19 19:05



Tuve un problema similar en mi proyecto y lo resolví poniendo el --preserve-merges opción para el comando rebase. En mi proyecto, este problema fue causado por un commit de fusión, que es un "commit vacío". Utilizando git rebase --preserve-merges toma la combinación de commit y continúa la fusión sin romper el árbol de commit.


1
2018-04-12 21:36



Bien podría significar que los cambios ya están redefinidos. Solo revisa el estado de git.


0
2018-02-19 18:59