昨天我们用git来解决这个非常奇怪的情况：
我们一如既往地创建了一个功能分支。然后，有人会在该功能分支上工作几天。
与此同时，主分支上发生了重要的事情。功能分支也需要这些更改。
因此，我们将master分支合并到功能分支中（没有rebase，因为我们的功能分支通常会立即推送到远程，因为我们需要在功能上进行协作）。此合并仅在本地完成，尚未推送到远程。
继续处理功能分支
随着master的合并+继续工作，本地功能分支new_feature现在领先于origin / new_feature 40次提交
现在我们想将这40个提交推送到远程功能分支。首先，我们在推送之前做了一个git pull --rebase，因为其他人可能会在我们面前推送一些提交。
现在我们遇到了大量的冲突。我们认为不值得修复40次提交并进行git rebase --abort。然后我们尝试git pull --no-rebase。我们得到：“已经是最新的” - 奇怪的
由于git status没有告诉我们我们的本地分支和远程分支有分歧，我们尝试git push
出乎意料的是，git push工作了。如果我们试图推送自上次提取以来已经发生变化的远程分支，我们会被拒绝。所以很明显遥远没有改变，但是git pull --rebase做了一些奇怪的事情。
所以这有什么奇怪的是
git pull --rebase没有立即返回“已经是最新的”和
git pull --rebase报告了大量的冲突，真正没有人应该退出（报告的冲突与功能分支上的工作无关）
可能导致这种情况的原因是什么？
答案 0 :(得分：2)
即使你已经启用了rerere，或者如果你能解决所有40个冲突，我也会得到你预期的结果。问题是：你做了一个rebase，但你想提交一个合并！通过调用＆＃34; git pull --rebase＆＃34;，git将执行＆＃34; git rebase origin / featureXY＆＃34; （假设您的功能分支称为featureXY）。此外，如果原点没有更改，则在当前分支上执行rebase到原始分支的状态。当你在合并提交上执行rebase时，git会一如既往地执行。它解决了每个合并并创建了平坦的历史记录。这意味着，之前合并到分支中的主服务器的每次提交都将应用于您的分支。结果将是没有任何合并提交的直接历史记录。
结论：避免混合使用rebase并合并！在您的工作流程中，不可避免地直接推送合并，或者您无法继续使用pull-rebase。
答案 1 :(得分：1)
不幸的是，rebase之后的git merge会导致此问题，除非您之前已启用git rerere。见git rebase after previous git merge