Git 限制

  • 發行項

Azure DevOps Services

我們對 Azure Repos 中的 Git 存放庫施加一些資源限制。 我們的目標是確保所有客戶的可靠性與可用性。 另外，藉由保留合理的資料量和推送次數，您可以預期獲得更好的 Git 整體體驗。

Git 參與速率限制，以及其餘Azure DevOps Services。 此外，我們會對檔案和目錄路徑的大小總計、推送和長度施加限制。

存放庫大小

存放庫不應大於 250 GB。 若要擷取存放庫的大小，請在命令提示字元中執行 「git count-objects -vH」，並尋找名為 「size-pack」 的專案：

D:\my-repo>git count-objects -vH

count: 482
size: 551.67 KiB
in-pack: 100365
packs: 25
size-pack: 642.76 MiB   <-- size of repository
prune-packable: 83
garbage: 0
size-garbage: 0 bytes

建議您將您的存放庫保持在 10 GB 以下，以獲得最佳作業。 如果您的存放庫超過此大小，請考慮使用 Git-LFS、 Scalar或 Azure Artifacts 來重構您的開發成品。

Azure Repos會持續減少整體大小，並藉由將類似的檔案合併成套件來提升 Git 存放庫的效率。 對於接近 250 GB 的存放庫，可以在優化程式完成之前，達到套件檔案的內部限制。 任何嘗試寫入存放庫的使用者都會看到下列錯誤訊息：「已達到 Git 套件檔案限制，在更新存放庫時暫時無法使用寫入作業」。作業完成之後，會立即還原寫入作業。

推送大小

大型推播會佔用大量資源、封鎖或變慢服務的其他部分。 這類推播通常不會對應至一般軟體發展活動。 例如，有人可能不小心簽入組建輸出或 VM 映射。 基於這些原因等等，推播一次限制為 5 GB。

有一個例外狀況是大型推播正常。 當您將存放庫從另一個服務遷移至Azure Repos時，它會以單一推送的形式傳入。 我們不想封鎖匯入，甚至是非常大型的存放庫。 如果存放庫超過 5 GB，您必須使用 Web 匯入 存放庫 ，而不是命令列。

LFS 物件的推送大小

Git LFS 不會計入 5 GB 存放庫限制。 5 GB 的限制僅適用于實際存放庫中的檔案，而不是儲存為 LFS 一部分的 Blob。 如果您在 5 GB 的限制上收到失敗的推送，請確認您的 .gitattributes 檔案包含您表示使用 LFS 追蹤的副檔名，而且此檔案已儲存並暫存，再暫存要追蹤的大型檔案。

路徑長度

Azure Repos具有推播原則，藉由拒絕引進太長路徑的推送，來限制 Git 存放庫中路徑的長度。 不同于 [路徑長度上限] 原則，無法停用或覆寫此原則有不同的限制，因為它會強制執行平臺所支援的最大可能值。

強制執行兩個限制：

  • 路徑長度總計：32，766 個字元
  • 路徑元件長度 (，也就是資料夾或檔案名) ：4096 個字元

它只會影響推送中新引進的路徑。 如果您變更現有的檔案，則不適用。 但是，如果您建立新的檔案或重新命名或移動現有的檔案，它就會套用。

如果某些正在推送的認可導入超過限制的路徑，則會拒絕推送，並出現下列其中一個錯誤訊息：

  • VS403729: The push was rejected because commit '6fbe8dc700fdb33ef512e2b9e35436faf555de76' contains a path, which exceeds the maximum length of 32766 characters.
  • VS403729: The push was rejected because commit 'd23277abfe2d8dcbb88456da880de631994dabb4' contains a path component, which exceeds the maximum length of 4096 characters.