對於像Bitbucket，GitHub和Launchpad這樣的源代碼託管設施如何實際管理主存儲庫中的分叉進程，以及當這些存儲庫在服務器端分支時如何保存其服務器磁盤空間，我只是有點好奇，側。版本控制：如何在源代碼託管設施上分配存儲庫？

例如，如果我從GitHub上的存儲庫分叉：我的存儲庫上的複製代碼是否從GitHub服務器上的主存儲庫獲取額外的磁盤空間（我的意思是它會導致存儲重複）？

在此先感謝。

2016-06-21 Kais

基於this answer看來，Github上，至少，不會複製存儲庫時，它分叉。相反，它會創建具有預設用戶名的新分支（例如，代替master，我的分支主分支將被引用爲lightcc.master）。

這在Git如何存儲文件並引用它們以及爲什麼能夠如此高效地存儲回購庫的情況下非常合理。如果一個fork是一個repo的完美副本，那麼所有需要完成的工作就是創建新的分支（跟蹤引用）並跟蹤誰有權查看它們並將它們推送到它們/從中獲取。如果我發佈了回購協議，但從未對其進行修改，那麼我的跟蹤參考可能位於上游回購協議後面，但它們將始終與舊協議相同（除非原始回購協議有一些非常糟糕的情況[tm]和通過rebasing，壓扁等方式將其歷史記錄重寫爲現有的提交）。

換句話說，在原始分叉時，原始repo都不需要複製，因此唯一的成本就是創建新的跟蹤引用所需的字節數，即每個現有分支約40字節。它可能甚至不能創建新的引用，直到你真的與原始回購存在分歧（或者直到你設置了一個跟蹤引用並將它推到給定的分支的叉上 - 所以主機可能是自動的？）。

鑑於這些評論，看起來這就是Github所做的，因此Gitlab實際上覆制repo的行爲（每個0xcaff的答案）更類似於創建重複進程的Unix fork。 Github以一種非常敏捷的方式想要等到最後一刻才能創建任何新對象，因爲叉子實際上與原始回購存在分歧。

這可能就是爲什麼Github有一些關於從原始回購中完全分離分支的規則，以及爲什麼需要涉及支持。這樣做會花費他們的存儲空間，並且如果他們讓所有人都輕鬆且免費地做到這一點，那麼隨着時間的推移，這可能會讓他們花費大量存儲空間等等。

來源

2017-09-11 07:25:37 LightCC

這是一個很好的問題，讓我想知道同樣的事情。

Gitlab

幸運的是，有一個名爲gitlab，我們可以看到一個開源的混帳回購協議的管理工具。

在gitlab-shell中，fork_project函數處理分叉。檢查是否通過PARAMS後執行以下行有效：

cmd = %W(git clone --bare -- #{full_path} #{full_destination_path}) 
system(*cmd) && self.class.create_hooks(full_destination_path)

所以GitLab簡單地克隆庫，複製源代碼。

版本控制：如何在源代碼託管設施上分配存儲庫？

回答

Gitlab

相關問題