我已經淺克隆了一個深度為 1 的存盤庫，并創建了一個本地開發分支進行開發。提PR后，收到合并沖突，所以拉了最新的master，嘗試和dev分支合并。
方法一：
- 當我試圖拉樹枝時，它說
fatal: refusing to merge unrelated histories - 所以，我洗掉了本地master并使用switch創建了一個新分支
git switch -c master origin/master - 現在，當我嘗試將主分支合并到本地以解決合并沖突時，我收到了錯誤
fatal: refusing to merge unrelated histories
方法二：
- 方法 1 中的步驟 2 相同。
- 我試圖挑選導致我的合并沖突的提交。由于 repo 是淺克隆的，它沒有提交歷史并拋出錯誤
bad object。
我試過–allow-unrelated-histories了，有很多合并沖突必須手動修復。
如何解決此問題并將 master 合并到我的 dev 分支？
uj5u.com熱心網友回復：
從不1使用--allow-unrelated-histories. 相反，加深（或“不淺”）你的克隆。編輯：根據評論，您還需要將克隆轉換為完整克隆（它目前是單分支克隆，我應該預料到，因為--depth在克隆期間使用默認創建單分支克隆也是如此）。
在 Git 中，合并取決于三個提交，而不是兩個：
- 有你當前的提交（又名
HEAD），它將代表自某個共同起點以來完成的作業； - 還有一些其他的提交，它將代表自同一個共同起點以來在其他一些分支中完成的作業；和
- 還有第三個提交，即合并基礎，這是這個共同的起點。
當你運行git merge時，你提供的引數——通常是一個像featureor這樣的分支名稱——master位于這三個的中間：“其他”或--theirs提交。當前或--ours提交是由您簽出的內容所暗示的。第三次提交，共同的起點，Git 自己找到。但是 Git需要歷史來找到這個提交。
在 Git 存盤庫中，歷史無非就是存盤庫中的提交。一個正常的、非淺層的克隆有所有的 commits，2所以它有所有的歷史。淺層克隆的重點是為了權宜之計故意省略一些歷史。出于某些目的，這很好（因此實際上是權宜之計）。對于合并它不好；不要這樣做。
如果你有一個現有的淺克隆，例如，因為你的 CI 系統做了一個，請考慮運行：
git remote set-branches origin "*"
git fetch --unshallow
第一個命令將克隆轉換為標準的完整克隆（撤消單分支）。請注意，您可能可以輸入*不帶引號的內容，但使用這樣的引號應該始終有效。
第二個命令重定向通常的git fetch操作，以便消除膚淺。如果這被證明在系統資源方面使用過多，您可以交替使用git fetch --depth或git fetch --deepen逐步向淺層存盤庫添加更多提交，直到您有足夠的歷史記錄（足夠的提交）git merge來定位公共起點。這種方法的問題在于無法保證該深度可能有多深，這意味著沒有正確的方法來選擇正確的深度。這反過來又意味著一個回圈，在其中你反復加深深度直到它“足夠”，并且每次使用越來越多的系統資源，這大概是您首先通過淺克隆試圖避免的。
大多數確實進行淺克隆的 CI 系統都為您提供了一種首先強制進行完整克隆的方法（這總體上比進行淺克隆然后取消淺克隆更有效）。因此，如果淺克隆是問題所在，就像在這種情況下，請不要一開始就這樣做。
1高級 Git 用戶的規則：--allow-unrelated-histories在你以某種方式證明它是可以的之前，永遠不要使用它。
2請記住，git clone操作的核心是復制所有提交，但不復制任何分支名稱。Git不需要分支名稱來運行，但它確實需要提交。我們——人類——不喜歡在沒有分支名稱的情況下使用 Git，所以我們總是讓 Git 創建一些，盡管 CI 系統有時不會打擾它們；我們使用分支名稱和/或遠程跟蹤名稱（它們記住一些其他存盤庫的分支名稱）來查找有趣的提交。Git 也可以使用這些，但可以直接使用原始哈希 ID，這就是那些 CI 系統的作業方式。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/526286.html