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

Estoy tratando de rebase 'dev' para ponerse al día con la rama 'master'.

$ git checkout dev 
$ git rebase master 
First, rewinding head to replay your work on top of it...
Applying: Corrected compilation 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 compilation 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 compilation 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 rebaseatascado. Una es si los cambios se vuelven nulos (una confirmación tiene cambios que ya se realizaron anteriormente en la nueva versión) en cuyo caso es posible que deba usargit rebase --skip .

Es bastante fácil saberlo. Si lo hace, git statusno debería mostrar cambios. Si es así, solo sáltatelo. Si ese no es el caso, publique una copia de git statusy puedo intentar ayudarlo más.

Una de las veces que me he encontrado con este problema es cuando hago un git commitafter a git add. Entonces, la siguiente secuencia producirá el error de rebase que usted menciona:

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

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

Es posible que git add -Acon la opción "Todos" se cree una situación similar. (Tenga en cuenta que no tengo mucha experiencia en git, por lo que esta respuesta puede no ser correcta). Para estar seguro, git rebase --skipparece que también funciona bien en esta situación.

Nota: Git 2.0.2 (julio de 2014) ha solucionado un caso en el git rebase --skipque a se atascaba y no podía continuar con el rebase actual.
Ver commit 95104c7 por brian m. carlson ( bk2204)

rebase--merge: arreglo --skipcon dos conflictos seguidos

Si se git rebase --mergeencuentra un conflicto, --skipno funcionaría si la próxima confirmación también entrara en conflicto .
El msgnumarchivo nunca se actualizará con el nuevo número de parche, por lo que no se omitirá ningún parche, lo que dará como resultado un bucle ineludible.

Actualice el msgnumvalor del archivo como lo primero en call_merge.
Esto también evita un Already appliedmensaje " " al omitir una confirmación.
No hay cambios visibles para los otros contextos en los que se invoca call_merge, ya que el valor del archivo msgnum permanece sin cambios en esas situaciones.

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

Parece que olvidaste git addtus cambios ...