如果你是在Mac OS X中，那么首先你应该禁用revisiond，因为它会在rebase的过程中扰乱你的工作树中的文件，导致不可预测和破坏的行为：

git config --global core.trustctime false

这个问题在this article中有解释，非常感谢@nickfalk指出了这个问题。
至于你的rebase，这种情况在实践中并不罕见。让我们试着想想发生了什么的步骤：

• 当你在另一个分支的顶部重定当前分支的基时，git会将HEAD移动到另一个分支，并开始应用你在当前分支中拥有的唯一提交。
• 在重播其中一个提交时，您遇到了冲突。您解决了它，但结果是没有要提交的更改，在此提交中没有要重播的内容。

实际上，这意味着你拒绝了正在重放的当前提交中的更改。所以，如果你不需要这个提交中的任何东西，跳过它是正常的。所以git rebase --skip在这里是有意义的。

我在我的项目中遇到过类似的问题，通过在rebase命令中添加--preserve-merges选项解决了这个问题。在我的项目中，这个问题是由合并提交引起的，这是一个“空提交”。使用git rebase --preserve-merges，它接受合并提交并继续合并，而不会破坏提交树。

呼吸，你不会发疯的！-=这是一个已知的bug，OSX（如果你确实在使用它的话）正在干扰git;它是详细的by Tower（不是由我）。
简短的故事（即修复）是：

git config --global core.trustctime false

我尝试了所有的方法，但都不起作用。如果你没有在rebase中，但git一直在抱怨，那么试试下面的方法。这对我在OSX上很有效。
rm -fr ".git/rebase-apply"

git add .会解除对你的封锁，但是如果你通过接受传入的修改来解决所有的冲突，那么就没有diff可以添加了，所以git认为就rebase而言，冲突还没有解决。
我采取了一种低调的方法，它的工作不依赖于使用神秘的git配置更改等的副作用：

• 在每个冲突文件中添加无害的内容（例如//在一行）（给予git一些add的内容）
• git add .
• git rebase --continue
• 删除无害的评论

都整理好了🙂

这很可能意味着更改已经被重定基。只需检查git状态即可。

我发现我有这个问题是因为我硬重置了master分支，而我的feature分支有一些遗留的master提交（不要问我怎么做的-不知道：（））。
我把我的修改复制到一个临时目录，删除了我的特性分支，再把它们复制回去，然后从头开始。很难看，但很有效。如果你想在特性分支中保留多个提交，不建议使用。除非你已经尝试了 Everything ELSE，否则不建议使用。
更新：这是有效的，但在下面的评论中已经向我指出了更好的方法。看看吧。