Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Git 有助於保持原始程式碼的使用量很小，因為很容易挑選版本之間的差異，而且程式代碼很容易壓縮。 大型檔案不易壓縮，而且在版本之間會完全變更（例如二進位檔案），因此在 Git 存放庫中儲存這類檔案時會有問題。 Git 的快速效能來自於其處理和切換至本機記憶體中檔案的所有版本的能力。
如果您的存放庫中有大型且無法變動的檔案（例如二進位檔），則每次認可變更時，都會在存放庫中保留這些檔案的完整複本。 如果存放庫中有許多版本的這些檔案存在，它們會大幅增加簽出、分支、擷取和複製程式代碼的時間。
您應該在 Git 中儲存哪些類型的檔案？
提交原始程式碼，而非依賴項
當小組使用編輯器和工具來建立和更新檔案時，您應該將這些檔案放入 Git 中，讓您的小組享有 Git 工作流程的優點。 請勿將相依性檔案提交至您的存放庫，例如 DLL、函式庫檔案，以及小組未建立但程式碼依賴的其他相依性。 透過 套件管理將這些檔案傳遞至您的系統。
套件管理會組合您的相依性，並在部署套件時在您的系統上安裝檔案。 套件已設定版本，以確保在某個環境中測試的程式代碼會在另一個環境中執行相同，只要環境已安裝相同的套件。
不要提交輸出
請勿提交來自於組建和測試的二進位檔、日誌、追蹤輸出或診斷數據。 這些是來自程式代碼的輸出，而不是原始程式碼本身。 透過 工作專案追蹤 工具或團隊文件共享，與您的小組共享追蹤資訊和記錄。
在 Git 中儲存小型、不常更新的二進位來源
不常更新的二進位來源檔案有相對較少的認可版本。 如果檔案大小很小，則不會佔用太多空間。 Web、圖示和其他較小藝術資產的影像可能屬於此類別。 最好將這些檔案與其餘來源儲存在 Git 中，讓小組可以使用一致的工作流程。
這很重要
即使小型二進位檔經常更新，也會造成問題。 例如，對 100 KB 二進位檔所做的 100 次變更所使用的儲存空間，與對 1 MB 二進位檔所做的 10 次變更使用的一樣多。 由於更新頻率較高，較小的二進位檔在分支性能方面會比大型二進位檔更容易受到影響。
請勿提交大型且經常更新的二進位資產
Git 會管理檔案的一個主要版本，然後只儲存該版本的差異，這個過程稱為 deltification。 差分化和檔案壓縮可讓 Git 將整個程式碼歷程儲存在本地資料庫中。 大型二進位檔通常會在版本之間完全變更，而且通常已經壓縮。 由於版本之間的差異很大，因此 Git 難以管理這些檔案。
Git 必須儲存每個檔案版本的完整內容，並且難以通過差異化處理和壓縮來節省空間。 儲存這些檔案的完整版本會導致存放庫大小隨著時間增加。 增加的存放庫大小可減少分支效能、增加複製時間，以及擴充記憶體需求。
使用大型二進位原始程序檔的策略
- 請勿提交壓縮檔案。 最好解壓縮文件，並提交可比較的原始檔。 讓 Git 處理壓縮存放庫中的數據。
- 避免提交編譯過的程式代碼和其他二進位相依性。 認可來源並建置相依性，或使用套件管理解決方案來設定版本，並將這些檔案提供給您的系統。
- 以可變動的純文本格式儲存組態和其他結構化數據，例如 JSON。
什麼是 Git LFS？
當您有版本與頻繁更新之間差異很大的來源檔案時，您可以使用 Git 大型檔案記憶體 （LFS） 來管理這些文件類型。 Git LFS 是 Git 的延伸模組，提供資料以描述儲存庫提交中的大型檔案。 它會將二進位檔內容儲存在個別的遠端記憶體中。
當您複製並切換存放庫中的分支時，Git LFS 會從該遠端儲存體下載正確的版本。 您的本機開發工具會無縫地處理檔案，就像是直接提交到您的資料庫一樣。
優點
Git LFS 的優點是，不論小組建立的檔案為何，您的小組都可以使用熟悉的端對端 Git 工作流程。 LFS 會處理大型檔案，以防止它們對整體存放庫造成負面影響。 此外，從 2.0 版開始，Git LFS 可支援檔案鎖定，以協助小組處理大型、無法差異的資產，例如影片、音效和遊戲地圖。
Git LFS 在 Azure DevOps Services中完全支援且免費。 若要搭配 Visual Studio 使用 LFS，您需要 Visual Studio 2015 Update 2 或更新版本。 只要遵循 指示來安裝用戶端、設定本機存放庫上檔案的 LFS 追蹤，然後將變更推送至 Azure Repos。
局限性
Git LFS 有一些缺點，您應該先考慮再採用它：
- 您的小組所使用的每個 Git 用戶端都必須安裝 Git LFS 用戶端，並瞭解其 追蹤組態。
- 如果未正確安裝並設定 Git LFS 用戶端，當您複製您的存放庫時，將不會看到透過 Git LFS 提交的二進位檔。 Git 會下載用來描述大型檔案的資料（也就是 Git LFS 對儲存庫所提交的內容），而不是下載二進位檔案。 在未安裝 Git LFS 客戶端的情況下認可大型二進制檔案，會將二進制檔案推送至您的存放庫。
- Git 無法合併兩個不同版本的二進位檔變更，即使這兩個版本的父系是同一個也不行。 如果有兩個人同時處理相同的檔案，他們必須合作協調自己的變更，以免覆寫其他人的工作。 對此，Git LFS 提供了檔案鎖定。 在開始工作之前，使用者仍必須小心地一律提取二進位資產的最新複本。
- Azure Repos 目前不支援在包含 Git LFS 追蹤檔案的版本庫中使用安全殼層（SSH）。
- 如果使用者透過 web 介面將二進位檔拖曳至針對 Git LFS 設定的存放庫，則二進位檔會提交至存放庫，而不是透過 Git LFS 用戶端提交的指標。
- 雖然沒有嚴格的檔案大小限制，但伺服器的可用可用空間和目前的工作負載可能會限制效能和功能。
- 一個檔案上傳的時間限制為一小時。
檔案格式
寫入您存放庫中的 Git LFS 追蹤檔案有幾行，每行包含一個索引鍵/值組：
version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023
備註
針對版本值所包含的 GitHub URL 只會定義 LFS 指標檔案類型。 這不是二進位文件的連結。
已知問題
如果您使用 2.4.0 之前的 LFS 版本搭配 Azure DevOps Server，則需要額外的設定步驟，才能透過 NTLM 進行驗證，而不是透過 Kerberos進行驗證。 從 LFS 2.4.0 起，此步驟已不再需要，強烈建議您升級。