使用 --depth 1 進行淺克隆、創建提交並再次拉取更新是否安全？

Question

git clone的--depth 1選項：

創建一個將歷史記錄截斷為指定修訂數量的淺層克隆。 淺層存儲庫有很多限制（你不能從它克隆或獲取，也不能從它推入或推入），但如果你只對一個歷史悠久的大型項目的近期歷史感興趣，並且想要將修復作為補丁發送。

但是我已經成功地完成了一個淺層克隆，提交了一些更改並將這些更改推送回（裸克隆）源。

這對我來說很有意義 - 我的意思是為什么不呢？ 當克隆的 HEAD 在源中可識別，並且我的提交位於此之上時，似乎沒有任何理由。 但手冊上另有說明。

我喜歡淺層克隆的想法 - 例如 drupal 核心：當我從 7 開始時，我沒有辦法知道在 drupal 4 中發生了什么。 - 但我不想用腳射擊自己。

那么淺層克隆、在其中開發提交、再次拉取以跟上來自源的更新是否安全？

Answer 1

請注意，Git 1.9/2.0（2014 年第一季度）已刪除該限制。
請參閱來自Nguyễn Thái Ngọc Duy ( pclouds ) 的提交 82fba2b ：

現在 git 支持從淺層克隆或向淺層克隆傳輸數據，這些限制不再成立。

文檔現在顯示：

--depth <depth>::

創建一個“淺”克隆，其歷史記錄被截斷為指定數量的修訂。

這源於諸如0d7d285 、 f2c681c和c29a7b8 之類的提交，它們支持克隆、使用/來自淺層克隆的發送包/接收包。
smart-http 現在也支持淺取/克隆。

所有細節都在“ shallow.c ：為.git/shallow選擇新提交的 8 個步驟”中。

2015 年 6 月更新： Git 2.5 甚至允許獲取單個提交！
（終極淺表）

---

2016 年 1 月更新：Git 2.8（2016 年馬赫數）現在正式記錄了獲取最小歷史記錄的做法。
請參閱提交 99487cf 、 提交 9cfde9e （2015 年 12 月 30 日）、 提交 9cfde9e （2015 年 12 月 30 日）、 提交 bac5874 （2015 年 12 月 29 日）和提交 1de2e44 （2015 年 12 月 28 日）由Stephen P. Smith (``) 提交。
^{（由Junio C gitster合並-- gitster -- in commit 7e3e80a ，2016 年 1 月 20 日）}

這是“ Documentation/user-manual.txt ”

<<def_shallow_clone,shallow clone>>是通過指定git-clone --depth開關創建的。
稍后可以使用git-fetch --depth開關更改深度，或者使用--unshallow恢復完整歷史記錄。

只要合並基礎在最近的歷史記錄中，就可以在<<def_shallow_clone,shallow clone>>內部合並。
否則，就像合並無關的歷史一樣，可能會導致巨大的沖突。
這種限制可能使這樣的存儲庫不適合在基於合並的工作流中使用。

2020 年更新：

• git 2.11.1 引入了選項git fetch --shallow-exclude=以防止獲取所有歷史記錄
• git 2.11.1 引入了選項git fetch --shallow-since=以防止獲取舊提交。

---

有關淺克隆更新過程的更多信息，請參閱“如何更新 git 淺克隆？ ”。

---

正如理查德邁克爾評論的那樣：

回填歷史： git pull --unshallow

Olle Härstedt 在評論中補充道：

回填部分歷史記錄： git fetch --depth=100 。

Answer 2

查看我的類似問題為什么-cant-i-push-from-a-shallow-clone 的一些答案以及指向 git 列表上最近線程的鏈接。

最終，repos 之間的“深度”測量不一致，因為它們從各自的 HEAD 進行測量，而不是 (a) 您的 Head，或 (b) 您克隆/獲取的提交，或 (c) 其他東西你想到了。

難點是讓一個用例正確（即自洽），這樣分布式的，因此可能不同的存儲庫仍然可以愉快地一起工作。

看起來checkout --orphan是正確的“設置”階段，但仍然缺乏關於“克隆”步驟的清晰（即簡單易懂的單行命令）指導。 相反，看起來您必須init一個 repo，設置一個remote跟蹤分支（您確實只想要一個分支？），然后fetch該單個分支，這感覺很長，有更多的錯誤機會。

編輯：對於“克隆”步驟，請參閱此答案