有几种情况下，我看到rebase卡住了。一种情况是如果更改变为null（提交中的更改已经在rebase中进行过），在这种情况下，您可能必须使用git rebase --skip。
很容易分辨。如果执行git status，则应该不会显示任何更改。如果是的话，就跳过它。如果不是这样的话，请发布一个git status的副本，我可以尝试进一步帮助。

我遇到这个问题的一次是在git add之后执行git commit。因此，以下序列将产生您提到的rebase错误：

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

而下面的序列运行时没有任何错误，并继续变基：

git add <file with conflict>
git rebase --continue

带有“All”选项的git add -A可能会产生类似的情况。（请注意，我对Git非常缺乏经验，所以这个答案可能不正确）为了安全起见，git rebase --skip在这种情况下似乎也能很好地工作。

注意：Git 2.0.2（2014年7月）修复了一个git rebase --skip被卡住而无法继续进行当前的变基的情况。
请参见commit 95104c7 by brian m. carlson ( bk2204 )

rebase--merge：修复--skip与两个冲突在一行

如果git rebase --merge遇到冲突，--skip将无法工作，如果下一个提交也发生冲突。
msgnum文件永远不会使用新的补丁编号进行更新，因此实际上不会跳过任何补丁，从而导致不可避免的循环。
在call_merge中首先更新msgnum文件的值。
这也避免了在跳过提交时出现“Already applied”消息。
调用call_merge的其他上下文没有明显的变化，因为msgnum文件的值在这些情况下保持不变。

在一次有很多冲突（长git status）的变基之后，我无法弄清楚我应该上演的是什么。我使用的是与PhpStorm集成的Git，它没有显示任何未暂存的文件。
git add .没有解决这个问题，但这条评论建议调用git diff-files --ignore-submodules。这显示了三个我必须专门添加的文件，这就成功了。

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

看起来你忘了git add你的变化...

当我有一个文件在两个分支中都被删除了一些提交时，我看到了这一点。我不得不git rm该文件，以获得rebase继续。
我试图重现这一点，但未能得到“无法继续”。如果有人想试试他们的手，这是我的尝试：

mkdir t
cd t
git init
echo a > a.txt && echo b > b.txt && git add . && git commit -m "+a +b"

git checkout -b no-a
echo b1 > b.txt && git add b.txt && git commit -m "~b1"
git rm a.txt && echo b2 > b.txt && echo c1 > c.txt && git add . && git commit -m "-a ~b +c"

git checkout main
git rm a.txt && echo b0 > b.txt && echo c0 > c.txt && git add . && git commit -m "~b +c"
git log --oneline --graph --decorate --all

git checkout no-a
git status
git rebase main
ls
cat b.txt
git status

git checkout no-a b.txt
git commit -m "-a ~b"
git rebase --skip

git checkout no-a c.txt && git checkout main a.txt
git commit -m "~b +c"
git rebase --skip