在櫻桃採摘的提交中使用git rebase有什麼後果？

假設我櫻桃挑選一些提交到我的分支git cherry-pick。之後，我們假設我將我的分支重新分配到我的父分支以獲得最新信息。 git會不會還記得這些提交已被挑選出來？這很重要，因爲我不希望這些提交會在我的分支合併回櫻桃挑選的父分支時變成啞巴衝突。在櫻桃採摘的提交中使用git rebase有什麼後果？

通過我的例子一步一步：

從分支A
承諾是在B和A提出創建分支B。
拉尖從分支A提交到使用git cherry-pick A
再次基於B分支B到A使用git rebase A（與B簽出）
當我運行git cherry會發生什麼？它會顯示櫻桃採摘的提交（這意味着它不再記得提交櫻桃採摘）？

如果櫻桃挑選關係在rebase後結束，rebase中的-p選項是否可以修復它？還是有其他解決方案來避免它？

來源

2014-09-24 void.pointer

一個ASCII圖有助於理解*哪些*提交你櫻桃採摘*哪裏*。 – Jubobs 2014-09-24 17:42:36

我給出了一個人爲的但簡單的例子。我不是ASCII藝術方面的專家。動用你的想象力。 – 2014-09-24 17:48:40

可能重複的[爲什麼在櫻桃選擇後不重複應用相同的提交？]（http://stackoverflow.com/questions/14509878/why-does-a-rebase-after-a-cherry-pick - 未申請最相同的提交，兩次） – Basilevs 2014-09-24 18:08:37

它不會在平凡的情況下顯示衝突 - 當挑選出來的變化不會受到重新變化的影響（在同一行範圍內沒有變化）。

在所有其他情況下會有衝突。

唯一能找到，會發生什麼的方法是嘗試這樣做（在一個單獨的分支中）。

這裏是一個book解釋：

如果上游分支已經包含所做的改變（例如，因爲你郵寄其上游施加貼片），則該提交將被跳過。例如，運行git變基上以下歷史主（其中A」和A引入同一組的變化，但有不同的提交者信息）：
 A---B---C topic 
    /
D---E---A'---F master 
將導致：
   B'---C' topic 
      /
D---E---A'---F master 

來源

2014-09-24 18:03:42 Basilevs

在櫻桃採摘的提交中使用git rebase有什麼後果？

回答

相關問題