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 套件檔案限制，在更新存放庫時暫時無法使用寫入作業。」優化作業完成之後，會立即還原寫入作業。

檔案不應大於 100 MB。 此限制有助於確保 Git 存放庫的最佳效能和可靠性。 大型檔案可能會大幅降低存放庫作業的速度，例如複製、擷取和推送變更。 如果您需要儲存大型檔案，請考慮使用 Git LFS （大型檔案記憶體），其設計目的是要透過將大型檔案儲存在主要存放庫之外，並只保留存放庫內的參考，以有效率地處理大型檔案。 此方法可協助維護 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 個字元
• 路徑元件長度（資料夾或檔名）：4,096 個字元

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

如果任何被推送的認可引進超過這些限制的路徑，推送會遭到拒絕，並出現下列其中一個錯誤訊息：

• 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.