理解git的問題提交

Question

我們有這得到了在過去莫名其妙地搞砸了......以下情況的一個分支的一些問題：

• d是一個輸送支路我們接收來自供應商的變化
• M是主分支
• F是一個特性分支從d
• 提交被合併到M
• F被重訂具有M
• M含有F（F2）的意外提交，M3是該復歸提交

 
      D 
    D1-D2-D3-o 
    \  \___________ 
     \     \ M 
     \-M1-M2-D2-F2-M3-D3-o 
     \  /
     \ / F 
      \-F1-F2-F3-o 

現在，我們正試圖再次變基f控制M類似但是我們與M3恢復的變化F2缺失到底。

  
      D 
    D1-D2-D3-o 
    \  \___________ 
     \     \ M 
     \-M1-M2-D2-F2-M3-D3-o 
         \ 
          \  F 
          \-F1-F3-o 

當分支˚F我們簡單地使用：

git pull --rebase origin master 

有爲什麼墊底F1-F2-F3在F2-M3將失去F2解釋？

看來工作似乎是將F中的所有更改壓縮到一個提交，然後進行rebase，在這種情況下，F2中引入的更改仍然存在。

我試圖用rebase交互模式重寫M的歷史並保留合併......我的想法是去除意外提交（F2）和它的恢復（M3），但結果並沒有給出我有信心，我沒有放棄任何東西。

另外我遇到以下（在這裏提到的錯誤：https://git-scm.com/docs/git-rebase），這讓我放棄了重寫主人歷史的想法。

由--preserve-merges --interactive提供的待辦事項列表不是 代表修訂圖的拓撲。編輯提交和 重新提交它們的提交消息應該可以正常工作，但嘗試重新排序提交往往會產生違反直覺的結果。

Answer 1

我會猜F2上M是F2上F一摘櫻桃而不是作爲圖形顯示合併。

時重訂基，git會摘櫻桃是在F所有提交但不是在M，如F2在兩個分支不選擇它。

如果你想保持它，一個解決方案是使用git rebase的所有參數：

git rebase --onto M $(git merge-base F M) F 
# equivalent to: 
# git rebase --onto M D1 F 

這將重訂的所有提交的F，但不是在M和F共同的祖先（D1 ）==>F1-F2-F3，在M

---

另一種解決方案到底是執行交互式變基（git rebase --interactive M F），然後前plicitly添加pick F2在底墊中，TODO：

pick F1 
pick F2 
pick F3