git pull --rebase因冲突而失败，但是git push工作正常

Question

昨天我们用git这个非常奇怪的情况：

1. 我们一如既往地创建了一个功能分支。 然后，有人会在该功能分支上工作几天。

2. 与此同时，主分支上发生了重要的事情。 功能分支也需要这些更改。

3. 因此，我们将master分支合并到功能分支中（没有rebase，因为我们的功能分支通常会立即推送到远程，因为我们需要在功能上进行协作）。 此合并仅在本地完成，尚未推送到远程。

4. 继续开展功能分支工作

5. 随着master的合并+继续工作，本地特征分支new_feature现在领先于origin / new_feature 40次提交

6. 现在我们想将这40个提交推送到远程功能分支。 首先，我们在推送之前做了一个git pull --rebase，因为其他人可能已经在我们之前推送了一些提交。

7. 现在我们经历了大量的冲突。 我们认为不值得修复40次提交并进行git rebase --abort。 然后我们尝试git pull --no-rebase。 我们得到：“已经是最新的” - 奇怪

8. 由于git status没有告诉我们我们的本地分支和远程分支有分歧，我们尝试git push

9. 出乎意料的是，git push工作了。 如果我们试图推送自上次提取以来已经发生变化的远程分支，我们会被拒绝。 所以很明显遥远没有改变，但是git pull --rebase做了一些奇怪的事情。

所以这有什么奇怪的

1. git pull --rebase没有立即返回“已经是最新的”和

2. git pull --rebase报告了大量的冲突，真正没有人应该退出（报告的冲突与功能分支上的工作无关）

什么可能导致这种情况？

Answer 1

即使你已经启用了rerere，或者如果你能解决所有40个冲突，我也能得到你预期的结果。 问题是：你做了一个rebase，但你想提交一个合并！ 通过调用“git pull --rebase”，git将执行“git rebase origin / featureXY”（假设您的功能分支称为featureXY）。 此外，如果原点没有更改，则在当前分支上执行rebase到原始分支的状态。 当你在合并提交上执行rebase时，git会一如既往地执行。 它解决了每个合并并创建了平坦的历史记录。 这意味着，之前合并到分支中的主服务器的每次提交都将应用于您的分支。 结果将是没有任何合并提交的直接历史记录。

结论：避免混合rebase并合并！ 在您的工作流程中，不可避免地直接推送合并，或者您无法继续使用pull-rebase。

Answer 2

不幸的是， git merge后的rebase会导致这种情况，除非你之前启用了git rerere。 在上一次git merge之后看git rebase