El conflicto de fusión de Git Rebase no puede continuar

Estoy tratando de rebase 'dev' para alcanzar la twig 'master'.

$ git checkout dev $ git rebase master First, rewinding head to replay your work on top of it... Applying: Corrected comstacktion problems that came from conversion from SVN. Using index info to reconstruct a base tree... M src/com/.... <stdin>:125: trailing whitespace. /** <stdin>:126: trailing whitespace. * <stdin>:127: trailing whitespace. */ <stdin>:128: trailing whitespace. package com.... <stdin>:129: trailing whitespace. warning: squelched 117 whitespace errors warning: 122 lines add whitespace errors. Falling back to patching base and 3-way merge... Auto-merging src/com/.... CONFLICT (content): Merge conflict in src/com/... Failed to merge in the changes. Patch failed at 0001 Corrected comstacktion problems that came from conversion from SVN. When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". $ vi src/com/..... { fixed the merge issue on one file } $ git add -A . $ git rebase --continue src/com/....: needs merge You must edit all merge conflicts and then mark them as resolved using git add $ vi src/com.... { verified, no >>> or <<< left, no merge markers } $ git rebase --continue Applying: Corrected comstacktion problems that came from conversion from SVN. No changes - did you forget to use 'git add'? If there is nothing left to stage, chances are that something else already introduced the same changes; you might want to skip this patch. When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". 

¿Algunas ideas?

Hay un par de situaciones en las que he visto rebase atascarse. Una es si los cambios se vuelven nulos (una confirmación tiene cambios que ya se hicieron previamente en la rebase) en cuyo caso puede que tenga que usar git rebase --skip .

Es bastante fácil de decir. Si haces git status no debería mostrar ningún cambio. Si es así, sáltelo. Si ese no es el caso, publique una copy del git status de git status y puedo intentar ayudarlo.

Nota: Git 2.0.2 (julio de 2014) ha corregido un caso en el que un git rebase --skip quedaba atascado y no podía continuar con la rebase actual.
Ver commit 95104c7 por brian m. carlson ( bk2204 )

rebase--merge : corregir --skip con dos conflictos en una fila

Si git rebase --merge encontró un conflicto, --skip no funcionaría si la siguiente confirmación también entraba en conflicto .
El file msgnum nunca se actualizaría con el nuevo número de parche, por lo que no se msgnum ningún parche, lo que daría como resultado un bucle ineludible.

Actualice el valor del file msgnum como lo primero en call_merge.
Esto también evita un post " Already applied " al omitir una confirmación.
No hay cambios visibles para los otros contexts en los que se invoca call_merge, ya que el valor del file msgnum permanece inalterado en esas situaciones.

 $ vi src/com.... { verified, no >>> or <<< left, no merge markers } $ git rebase --continue 

Parece que olvidó git add los cambios …

Una de las veces que me he encontrado con este problema es cuando hago un git commit después de git add un git add . Entonces, la siguiente secuencia producirá el error de rebase que mencionas:

git add <file with conflict>
git commit -m "<some message>"
git rebase --continue

Mientras, la siguiente secuencia se ejecuta sin ningún error y continúa la rebase:
git add <file with conflict>
git rebase --continue

Es posible que git add -A con la opción "Todos" esté creando una situación similar. (Tenga en count que no tengo mucha experiencia en git, por lo que esta respuesta puede no ser correcta.) Para estar seguro, el git rebase --skip también parece funcionar bien en esta situación.