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