我今天遇到了一种情况，即即使目标分支是我尝试重新基准的分支的直接祖先，重新基准也会失败。
我目前在分支changes-2021，正在尝试重新绑定到master:
$ git merge-base changes-2021 master
e335d3ebd223ad21cd53b2cf3f16876f01fc1aef
$ git show e335d3ebd223ad21cd53b2cf3f16876f01fc1aef
commit e335d3ebd223ad21cd53b2cf3f16876f01fc1aef (origin/master, origin/HEAD, master)
...
(so master is a direct ancestor)
$ git rebase master
...
CONFLICT (content): Merge conflict in frontend/src/style.scss
error: Failed to merge in the changes
...
这怎么可能？我本以为这次重组会像过去遇到类似情况一样完全平静。这次唯一的区别是，我试图重新绑定到的分支指向一个相当旧的提交(大约5个月前(，但它仍然是当前分支的直接祖先。
在执行常规重基时，如果目标分支是您希望重基的分支的直接祖先，则应发生以下两件事之一：
- 如果您的历史记录在目标分支之后是线性的，您将收到类似于"的消息；分行是最新的"这是因为使用默认选项重新调整基准不会有任何效果，所以它甚至不会尝试
- 如果您的历史记录在目标分支之后是非线性的，这意味着至少有一个新的合并提交，则它将尝试重播目标无法访问的所有提交，除了合并提交的
由于尝试了重新基准，我们知道您处于第2种情况(这也在评论中得到了证实(。至于为什么会发生冲突，这与任何合并都可能发生冲突的原因完全相同。分支上的某个合并提交(晚于目标分支(在最初创建时可能发生冲突，因此，当尝试线性重写该合并两侧的提交时，同样的冲突将再次发生。请注意，由于提交是在rebase中一个接一个地重播的，因此在这种情况下发生冲突的可能性实际上比您选择使用--rebase-merges选项重写合并提交的可能性更高。