Git 在新的父提交之上從一個父提交變基（沒有舊的父提交作為其父提交之一）

Question

編輯：我們正在使用 Gerrit。 本地更改傳輸到 Gerrit，在那里進行審查，然后（由 Gerrit）合並到遠程 master 分支。

很多時候我遇到了一個特定的 rebase 問題，這個問題超出了我對 Git 功能的有限理解。 想象一下下面的場景（雖然所有這些都在發生，但origin/master上沒有其他活動發生）：

您創建一個新的提交A ，它直接基於origin/master上的當前內容。 在A甚至合並到origin/master ，您已經創建了一個直接基於提交A的新提交B 。

現在，當提交A正在接受審查時，決定將提交A分成兩個單獨的提交。 因此，您創建一個直接基於origin/master的新提交A0並將A部分更改移動到新創建的A0 。 現在A0被合並，成為新的origin/master 。 接下來，原始A （現在更薄，因為它不再包含移動到A0 ）重新基於A0之上（即在origin/master之上），然后合並到origin/master 。 到現在為止還挺好。

接下來（准備將B合並到origin/master ）您嘗試在origin/master之上重新設置B 。 這就是一切都發生了可怕錯誤的地方（無論如何，對我來說）。

當我運行這些步驟（在 Git bash 中）時，我通常會重新設置更改：

• git fetch --prune
• git rebase 原點/主

Git 抱怨有一個必須手動解決的沖突。 就我而言，這是一個 changelog.txt 文件。 在B的原始歷史記錄中，這個 changelog.txt 文件包含一個合並的更改日志條目，用於以前合並的A0和A更改。 在新的父級B的基礎上，這個合並的更改日志條目現在已被拆分為 2 個單獨的更改日志條目，顯然這不是 Git 可以自動解決的問題。

我沒問題。 解決我自己不應該特別困難，所以我啟動了我的圖形合並工具。 然而，雖然合並工具讓我在一側的舊組合更改日志條目和另一側的新單獨更改日志條目之間進行選擇，但我注意到B本身提供的新更改日志條目完全丟失（無論是哪一個）我的選擇）！！ 我不明白為什么 Git 會忘記這部分。 我究竟做錯了什么？

Answer 1

問題是 B 站在原來的 A 之上……你可以這樣做：

git rebase --onto origin/master B~1 B

這樣，您只移動與 B 相關的唯一修訂，而不是來自 A 的任何修訂。如果與 B 相關的修訂不止一個，只需調整倒數第二個參數的修訂數量（3 個修訂） ?B~3)。