Я пытаюсь переустановить "dev", чтобы догнать ветку "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".
Любые идеи?
Есть пара ситуаций, когда я видел, как rebase застревает. Один из них - если изменения становятся нулевыми (у фиксации есть изменения, которые уже были сделаны ранее в rebase), и в этом случае вам, возможно, придется использовать git rebase --skip.
Это довольно легко сказать. Если вы выполняете git status, он не должен показывать никаких изменений. Если так, просто пропустите это. Если это не так, отправьте копию git status, и я могу попытаться помочь дальше.
Примечание. Git 2.0.2 (июль 2014 г.) зафиксировал один случай, когда git rebase --skip застрял и не смог бы продолжить текущую rebase.
См. совершить 95104c7 brian m. carlson (bk2204)
rebase--merge: исправить --skip двумя конфликтами в строкеЕсли
git rebase --mergeстолкнулся с конфликтом,--skipне будет работать, если следующий коммит также противоречит.
Файлmsgnumникогда не будет обновляться с новым номером патча, поэтому патч не будет пропущен, что приведет к циклу inescapable.Обновите значение файла
msgnumв качестве первой вещи в call_merge.
Это также позволяет избежать сообщения "Already applied" при пропуске фиксации.
Нет видимых изменений для других контекстов, в которых вызывается call_merge, поскольку Значение msgnum в этих ситуациях остается неизменным.
$ vi src/com.... { verified, no >>> or <<< left, no merge markers }
$ git rebase --continue
Похоже, вы забыли git add свои изменения...
В один из случаев, когда я столкнулся с этой проблемой, вы делаете git commit после git add. Таким образом, следующая последовательность приведет к ошибке, которую вы упомянули:
git add <file with conflict> git commit -m "<some message>" git rebase --continue
Пока последовательность ниже работает без ошибок и продолжает rebase: git add <file with conflict> git rebase --continue
Возможно, что git add -A с опцией "Все" создает аналогичную ситуацию. (Обратите внимание: я очень неопытен в git, поэтому этот ответ может быть неправильным.) Чтобы быть в безопасности, git rebase --skip, похоже, также хорошо работает в этой ситуации.