後，我有我的git倉庫以下（簡化）場景：重訂互動在提交妖異
A-B-C-F
\
D-E
提交F是對C的修復，這需要成爲一個提交。我試着使用git rebase -i HEAD~2「主」分支的互動變基，但這會導致以下：
A-B-CF
\
C-D-E
，而我希望它是這樣的：
A-B-CF
\
D-E
任何人知道如何實現這一目標？我還沒有推動任何東西。
爲了清楚起見，我會在這裏添加一些細節。
A-B-C-F (master)
\
D-E (featureA)
我將分支名稱歸屬於這些名稱，因爲它在談論重新綁定時會引起混淆。名字不重要，即時假設當你說「主」你的意思是頂行，我稱之爲主人。
您的問題實際上相當複雜，因爲您已經與其他分支「共享」C提交。現在您要修改該提交 - 這意味着您需要更改整個featureA分支的歷史記錄。
公平的警告。如果您已將這些分支包括C,F,D或E與任何其他開發人員發佈，他們將在重新分配之後出現嚴重問題。
git checkout master
git rebase -i HEAD~2
當你知道你那麼只需要修正內容或壓扁之前最後提交到一個。現在，你會真正有這一點。（假設符號「CF」表示組合C和F提交。
A-B-CF (master)
\
C-D-E (featureA)
發生這種情況，因爲C是master不再，但它是在featureA。最近的共同祖先的兩個分支是B。現在，您需要獲得C我們的featureA的歷史記錄。因此，在C之後的所有SHA1提交也將改變。
現在您需要結帳featureA和rebase master。
git checkout featureA
git rebase -i master
期間，您需要確保刪除表示C犯行了互動變基。如果你正確地做到這一點，你會得到這個。
A-B-CF (master)
\
D-E (featureA)
旁註
如果你不刪除C衍合過程中正確提交，你將結束與以下。
A-B-CF (master)
\
C-D-E (featureA)
這實際上非常接近我結束了。謝謝！我明白，當提交已被推送時，我不應該這樣做。我會接受這個答案，因爲澄清幫助我解決了問題，你只需要2個命令就可以完成它，而不必查找CF的哈希值。 ;） – 2013-04-09 16:45:21
剛纔意識到附註中的圖是錯誤的。更正它以顯示如果在重建過程中'C'沒有被移除會發生什麼。 – eddiemoya 2013-04-10 16:06:51
這就是我最終的結果。初步方案：
A-B-C-F (develop)
\
D-E (feature)
互動變基與git checkout develop; git rebase -i HEAD~2發展，擠壓˚F到C：
A-B-CF (develop)
\
C-D-E (feature)
互動的功能變基帶git checkout feature; git rebase -i HEAD~3，刪除C：
A-B-CF (develop)
\
D-E (feature)
最後一個正常在git rebase CF-hash上移動分支的起始位置：
A-B-CF (develop)
\
D-E (feature)
不知道這是否是最好的方法，但它似乎對我有用。
爲什麼不只是櫻桃選擇F進入E？或者如果CF的整個分支歷史是安全的，爲什麼不將F併入D-E？ – jeremy 2013-04-09 15:43:03
該分支是一個新的未完成的功能，F與此無關。它應該是C的一部分，它是在開始新功能之前發佈的。我想我可以將F合併到分支中，但如果可能的話，我不希望額外提交。也許我只是想過於「整齊」。 ;） – 2013-04-09 16:03:40