混帳：如何變基分支它被合併後，保持合併提交的變化

我有這樣的歷史：混帳：如何變基分支它被合併後，保持合併提交的變化

A - B - M 
\ /
    C

A，B和M是高手，C是一個特性分支。

我犯了兩個錯誤：

我沒有意識到，該公司遠程不接受合併提交之前，我做到了。
除了簡單地解決衝突之外，我在合併中改變了很多東西。

我想重新綁定，所以它看起來像A - B - C - M，C - M可能壓扁在一起。

我只發現one question on the internet which actually looked quite similar to my case，唯一的迴應是「合併很好」。我承認我仍然不是100％熟悉rebase語法，但任何組合我都告訴git有rebase，有或沒有-p和/或-i，它表示沒有任何可以rebase（noop）或說它不工作。

什麼似乎是合乎邏輯的選擇是踩C和rebase -ip master，但它不完全符合我的預期。

來源

2016-11-25 Martin S.

有了這樣的歷史：

A - B - M 
    \ /
    C

在男，你軟復位，B，和承諾，那麼你將最終A - B - M'這似乎是你想要什麼：

git checkout M 
git reset B 
git commit

分支的內容將保持不變，這些命令都沒有改變，只有C從歷史中消除，使它看起來像一個直分支。

來源

2016-11-25 17:40:28 janos

這將是'git checkout '和'git reset --soft B'，因爲新的提交是從索引的內容構成的，並影響當前分支（或分離的HEAD）。 – torek

這就像一個魅力，但我不知道爲什麼。爲什麼重置會執行此操作？ M不見了（重置往往會這樣做），C在單獨的分支上，但沒有人關心_him_。因此，重置軟基本上是使分支頭指向該提交併將diff作爲改變提交。這很好理解，特別是它不關心分支或任何東西，只有實際的變化？ –

當您進行軟重置時，工作目錄的內容不會改變。這是至關重要的。但HEAD指向您指定的某個版本。在那個時候，看着'git diff'，你會發現HEAD和你的內容之間存在差異。當你承諾時，自然，這些差異成爲新提交的內容。這很簡單。是的，我認爲可以說Git主要關心*實際變化*。這很有道理。 – janos

混帳：如何變基分支它被合併後，保持合併提交的變化

回答

相關問題