git push如何處理積壓

Question

我正在研究設置git服務器的分佈式部署。我意識到這是默認情況下git所做的事情，但在這種情況下，所有服務器都將作爲單一的事實來源，並提供集中支持提供的所有幫助。

目前我們的代碼庫和使用服務器的開發人員數量小（幾百個），但一旦部署我期待與他們的自動化生成至少一個數千用戶採用沿。當發生這種情況時，我預計將推動中央支持的git服務器數量增加多倍，這將導致增加推送到其他集中支持的git服務器。

爲了限制由所有這些服務器引起的推送風暴的可能性，我打算採用標準的集線器輻條架構，其中一個或兩個服務器充當主服務器，接收來自輻射服務器的推送並將這些變化推回到其他輻條。當我開始考慮從全球範圍講位於服務器上的樞紐備份多個推的影響

我的問題就出現了。我試圖在我的實驗室中模擬這種情況，並且從我所看到的推送過程只是等待其前面的過程完成。在小型部署中，這很好。但是，當您將構建自動化投入到工作中時，提交/推送活動可以呈指數級增長。如果我決定創建一個post-receive鉤子來處理這些按客戶端推送的推送，我可以預見這些進程可以在等待中心接收更改的客戶端服務器上備份的情況。

我的問題是：

我的顧慮是否有效？這些過程是否會將這些作品掛在外面，直到它們被中心收到爲止？客戶將不知道這種狀態，因爲推送過程將被分離出原始接收。但是，他們會發現其他遠程服務器上的更改會延遲。

如果這些進程會失敗，難道他們失敗是對的sshd的等待時間或根本的git本身具有指定等待區間的方法？

除了監視系統進程或包裝的推出指令跟蹤其完成時間，有沒有一種方法來檢測這種操作積壓，或爲此事掛得到在主服務器上的條件？

你任何人都可以點我對處理這個問題的一些主題或文章？

最糟糕的情況是，使用定時間隔的推送可以用於每個存儲庫，而不是基於掛鉤的推送，但我希望儘可能保持自由流暢，因此基於掛鉤的推送將是首選。

Answer 1

你真正看到一個推量如此之高，它可以在DOS的服務器？我不完全相信你的問題。

推動這樣的工作：

• 局端會談到遠程的一面位，足以弄清楚它需要轉什麼對象。
• 當地側包了所有必需的對象爲打包文件
• 本地端的打包文件傳輸到遠端，在那裏的一個臨時文件名
• 的打包文件重命名爲一個真正的文件名存儲傳送完畢。
• 儲存庫試圖按要求更新參（例如主分支指向新推提交它）

的轉移可以並行發生。所以你真正必須擔心的是你是否有足夠的網絡容量來維持所有的推動，我懷疑這是一個問題。推送和提取非常小。它們只傳送必需的對象（另一邊沒有的對象），並且它們基於另一邊已有的對象對內容進行增量壓縮，因此大小與傳送的大小成比例提交代表。如果你無法處理傳輸那麼多的數據，那麼我不確定分佈式源代碼控制系統能否爲你工作。

也就是說，如果兩個人同時推送到同一個分支，那麼您仍然可能遇到問題，更有可能的是，如果一個人認爲他們是最新的並且可以推送，那麼在他們設法推，別人推，所以第一個開發者必須在推之前拉。這些都是非常現實的問題，但通過發佈您的存儲庫，處理這些問題的方式是而不是。這是通過採用不會完全避免這種情況的工作流程。首先，如果你真的在尋找一千個開發人員，他們可能並不都在同一個倉庫中工作，對不對？如果他們......你可能想分解它。如果需要將某些事情綁定在一起，請查看子模塊。例如，這是如何存儲Linux內核源碼的。有很多位，每個位於它們自己的子模塊中，然後它們是父存儲庫的一部分。沒有多少人需要搗亂父庫;他們只是處理他們正在從事的子模塊的回購，並沒有太多人在爲此工作。你真的不想成爲擁有代表10M行代碼的單一存儲庫的情況。

現在，如果在分裂之後，你想進一步減少許多試圖推向一個分支的人的問題，那麼你可能想要停下來。讓一個集成商（或幾個）推到主要分支，並讓其他人只是推到他們自己的分支，集成者可以合併。這方面有很多很多變化，但你明白了。

最後，如果你可以避免它，儘量不要做hub/spoke事情。大型開源項目已成功從單個存儲庫託管，因此它似乎也可能適用於您。請記住，大多數操作是增量式（推/取），而不是全部（克隆），因此它們不會傳輸大量數據。如果需要考慮帶寬問題，您將再次得到正確分解存儲庫的幫助;這將減少要傳輸的數據量。