允許在git rebase中合併不相關的歷史記錄

Question

當您想要重新分配保持合併提交的分支時，您將通過--preserve-merges標誌。當你在git中合併不相關的歷史記錄時，你需要通過--allow-unrelated-histories標誌。

如果你正在做git rebase --preserve-merges當現有合併來自一個不相關的歷史，它失敗：

fatal: refusing to merge unrelated histories

如果你嘗試git rebase --preserve-merges --allow-unrelated-histories它失敗：

error: unknown option 'allow-unrelated-histories'

有一些其他的方式來告訴rebase允許合併？

---

編輯：這裏是一個最小的再現：https://github.com/vossad01/rebase-unrelated-merge-reproduction

要重現結帳master然後執行：

git rebase --preserve-merges --onto origin/a-prime HEAD~2 

Answer 1

蠻力方法是迫使一個共同的根源 - 因爲你」重新嘗試重新綁定根，沒有內容歷史記錄，做一個臨時空提交併告訴git這是您正在合併的歷史記錄的父代：

git rev-list --all --max-parents=0 \ 
| awk '{print $0,empty}' empty=`:|git mktree|xargs git commit-tree` \ 
> .git/info/grafts 
git rebase here 
rm .git/info/grafts 

Answer 2

當git rebase合併失敗時，它不會中止rebase，因此您有機會手動干預。

如果您願意手動解決這個問題，你可以完成合並如下：

git merge --allow-unrelated ORIGINAL_BRANCH_THAT_WAS_MERGED --no-commit 
git commit -C ORIGINAL_MERGE_COMMIT 
git rebase --continue 

理想的情況下，也將是Git的處理這種無需人工干預的方式。

Answer 3

To reproduce checkout master then execute:

git rebase --preserve-merges --onto origin/a-prime HEAD~2 -i

的混帳底墊文檔說不要合併-i和--preserve-merges。

[--preserve-merges] uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).

但即使沒有它仍然失敗，fatal: refusing to merge unrelated histories的-i。

部分問題是HEAD~2是origin/a-prime的直接祖先。您的測試回購看起來是這樣的：

1 [master] 
| 
2 
|\ 
| | 3 [origin/a-prime] 
| | | 
| 4/[origin/b] 
|/
|/
|/ 
5 [origin/a] 

的masterHEAD~2是5 origin/a-prime爲3.你的命令等同於：

git rebase -p --onto 3 5 

5是3的直接祖先，所以該命令沒有按」沒有什麼意義。如果這一切都有效，它會做一些奇怪的事情。

---

the cases I have encountered a couple of times recently have been in moving a project's documentation from GitHub Wiki to GitHub Pages (when the website already exists).

這是一個不恰當使用底墊。 Rebase將平行的歷史轉化爲線性歷史，基本上假設一組變化一直在另一組之上完成。這對於在功能分支正在處理時保持最新狀態是很好的，如果你沒有一堆中間的合併提交，它們什麼都不做，只是更新分支，那麼簿記和審查就更容易。這些對於閱讀代碼並在未來提交歷史的任何人都是喧囂的。

但是，當你有兩個真正發散的歷史時，最好留下它們作爲發散的歷史。合併它們會告訴我們正確的故事：網站和文檔是分開開發的，但是然後合併成一個單元。

1 - 3 - 5 
     \ 
    2 - 4 - 6 - 7 - 8 [master] 

您可以查看他們分別在拓撲次序（8,7，6,5，3，1，4，2），使用git log --topo-order或可以看看他們交織在日期順序（8,7， 6，5，4，3，2，1），默認爲git log。像gitk或GitX這樣的歷史可視化工具將同時顯示這兩個訂單。我們在網站上工作，然後我們在文檔上工作，然後在某個時間點（你必須找到一個點），出於某種原因，我們工作了一段時間在網站和文件一起。

1 - 3 - 5 - 2 - 4 - 6 - 7 - 8 [master] 

這會失去重要信息，並令人困惑，爲什麼某些變化在未來會變得更加困難。

做一個合併，這是正確的事情。