您的 Unity 專案太大，不適合使用 Git

每個 Unity 專案起初都很小。一個原型場景、幾個佔位貼圖，或許還有一段測試音效。接著專案逐漸擴大，版本庫也隨之膨脹。

沒人警告過你的資源問題

一個使用預設模板的全新 Unity 專案只有幾百 MB。當你加入了達到生產品質的紋理、動畫剪輯、音訊檔案、預製件（Prefabs）以及從 Asset Store 匯入的一堆套件後，這個數字便會輕鬆突破數十 GB。部分中型專案甚至會超過 50 GB。大型工作室的專案更是經常超過 100 GB。

Git 最初是為了追蹤文字而設計的。它在逐行比較 C# 腳本、合併分支以及維持乾淨的代码變更歷史方面表現極佳。但是二進位檔案（佔了 Unity 專案的大部分）卻很難進行比對。每當你更新一個 200 MB 的紋理圖集（Texture Atlas）或重新匯出一個角色網格（Mesh）時，Git 都會在歷史記錄中儲存一個該檔案的全新副本。這導致版本庫急劇膨脹，複製（Clone）速度慢如牛步，推送（Push）也頻頻逾時。

Git LFS 本應解決這個問題。它將版本庫中的大型檔案替換為輕量級的指標檔案，並將實際數據儲存在獨立的伺服器上。但在實際操作中，LFS 帶來了另一堆令人頭痛的問題。GitHub 等託管服務的頻寬限制可能會在一次推送中就耗盡免費額度。二進位檔案的鎖定工作流非常繁瑣。一旦你的 LFS 伺服器斷線或容量達到上限，整個團隊的工作就會停擺。

核心矛盾很簡單：Git 作為一個程式碼版本控制工具，卻被要求同時兼任資源儲存平台。這是兩項需求截然不同的工作。

是什麼讓 Unity 資源變得特別棘手

Unity 專案中充斥著版本控制系統難以處理的檔案類型。PSD 和 TGA 格式的紋理檔案每個可能達 50 到 500 MB。內含動畫的 FBX 模型往往有數十 MB。Unity 為了匯入品質而偏好使用的 WAV 格式音訊檔案體積龐大。烘焙的光照貼圖（Lightmapping data）、烘焙的遮擋（Baked Occlusion）以及地形高度圖（Terrain Heightmaps）都會產生大量的二進位輸出。

此外還有元數據（Metadata）的問題。Unity 會為每一個資源生成 .meta 檔案。這些是小型文字檔案，Git 單獨處理它們時沒有問題。但是，一個擁有數萬個資源的專案意味著有數萬個 .meta 檔案，專案資料夾的任何重新編排都會引發一連串的變更，使你的提交歷史（Commit History）變得雜亂無章。

接著是 Library 和 Temp 資料夾。有經驗的 Unity 開發者知道要將這些加入 .gitignore，但是當新手團隊成員第一次不小心提交了 Library 資料夾時，版本庫便會在單次提交中暴增數 GB。要從 Git 歷史記錄中清理這些內容，需要使用 BFG Repo-Cleaner 或 git filter-branch 等工具，而這兩者使用起來都絕非易事。

常見的折衷方案及其不足之處

多年來，團隊開發了各種策略。最常見的是使用託管提供商的 Git LFS。GitHub 提供 1 GB 的免費 LFS 儲存空間和 1 GB 的每月頻寬。對於一個正式的 Unity 專案來說，這些額度在一天之內就會耗盡。付費方案雖然有所幫助，但當你的版本庫包含 40 GB 的資源且多個團隊成員經常進行複製和拉取（Pull）時，成本會迅速上升。

有些團隊將專案拆分為兩個版本庫：一個用於程式碼，另一個用於資源。這雖然可行，但增加了複雜度。構建腳本需要知道去哪裡尋找這兩部分。新團隊成員需要複製兩個版本庫並設定正確的資料夾結構。持續整合（CI）流程也會變得更加脆弱。

另一些團隊則為整個專案採用 Perforce (Helix Core)。Perforce 能很好地處理大型二進位檔案，並具有完善的檔案鎖定功能。但它價格昂貴、維護複雜，如果你的程式碼庫規模不大，只是需要一個合適的地方來存放資源，這就顯得大材小用了。

網路連接儲存（NAS）和共享網路硬碟是另一種選擇。它們適用於小型本地團隊，但在面對遠端協作者時就會失效。透過家用網路同步數 GB 的數據速度極慢，而且缺乏內建的版本控制或搜尋功能。

將程式碼與資源分離

更切合實際的方法是讓每種工具各司其職。Git 負責處理你的 C# 腳本、著色器程式碼、編輯器腳本和設定檔。而合適的雲端硬碟則負責處理大型二進位資源：紋理、模型、音訊、影片參考、概念藝術和匯出的構建版本。

這正是 Fabric 的用武之地。Fabric 是一個雲端儲存和檔案管理平台，而不是遊戲引擎外掛程式或 Git 的替代品。它不會直接整合到 Unity 編輯器中，也不會像 Perforce 那樣管理資源版本。它所做的是為你的大型檔案在雲端提供一個合適的歸宿，可以從任何裝置存取，且不佔用本地儲存空間。

Fabric 的雲端硬碟提供隨選串流檔案功能。你的紋理、音訊檔案、參考資料和匯出的構建版本會像本地檔案一樣顯示在你的電腦上，但它們實際上存在於雲端。你不需要為了開始工作而在新筆記型電腦上下載 60 GB 的資源。你也不會因為本地硬碟在三個月前就耗盡了空間，而不得不塞滿外接 SSD。

對於開發 Unity 專案的開發人員來說，這種分離非常乾淨利落。你的 Git 版本庫保持輕量，僅包含能從逐行版本追蹤中受益的檔案。你的資源則存放在 Fabric 中，在那裡你可以瀏覽、搜尋和共享，而不會產生那些從未針對資源設計的版本控制系統所帶來的額外開銷。

在數萬個資源中找到你需要的內容

Unity 專案累積資源的速度比任何人整理的速度都要快。開發進行到第六個月時，專案資料夾已變成一個迷宮：Assets/Textures/Characters/Hero/v3_final_FINAL、Assets/Audio/SFX/Footsteps_Grass_New 等等。要找到正確的檔案，要麼需要知道確切的路径，要麼需要花十分鐘逐個點擊資料夾。

Fabric 的語意搜尋讓你可以描述你正在尋找的內容，而不是去回想你給它起了什麼名字。搜尋「草地腳步聲效果」，就能找到該檔案，即使它的名字是 step_outdoor_04.wav。搜尋「主角空閒動畫」，就能找到該剪輯，無論它最後落在了哪一個子資料夾中。

該平台還提供智能整理功能，可根據內容對檔案進行分類。當你從另一個開發者或工作室接手一個專案，並且需要理清一個在六個月前對別人來說很合理的資料夾結構時，這非常有用。

在引擎之外審查和共享資源

並非遊戲開發團隊中的每個人都在 Unity 編輯器中工作。美術總監需要審查紋理貼圖。音效設計師需要單獨聆聽音效。製作人需要查看環境美術的進度，而無需啟動一個需要花五分鐘才能打開的專案。

Fabric 的批註功能讓團隊成員可以直接在圖片上繪製，並在音訊和影片檔案上留下帶有時間戳記的評論。美術總監可以在紋理上的問題區域畫圈並留下筆記，美術人員無需打開 Unity 就能看到。這比截圖、在獨立的應用程式中打開、在上面繪製然後透過 Slack 發送要簡單得多。

對於與外部協作者、自由職業者或發行商共享資源，Fabric 的發佈功能可以建立包含連結分析的共享頁面。你可以看到誰在什麼時候查看了資源，這對於追蹤即時團隊之外的人員的批准和回饋非常有用。

與你其餘的工作流程協同工作

Unity 開發很少孤立進行。概念藝術來自 Photoshop 或 Procreate。模型來自 Blender 或 Maya。音訊來自 DAW。參考圖片來自網路、客戶簡報或情緒板。構建輸出則發送給測試人員、發行商或商店平台。

Fabric 可連結至 Google Drive、Dropbox 和其他服務，因此你可以從協作者已存放檔案的任何地方拉取檔案。如果你的概念美術設計師將作品存放在 Google Drive 中，而你的音效設計師使用 Dropbox，你可以透過 Fabric 存取這兩者，而無需要求任何人改變他們的工作流程。

AI 助手可以解答你所有檔案中的問題，這在你試圖回想哪個版本的資源已獲得批准，或者某張特定的參考圖片來自何處時非常有用。無需在 Slack 對話紀錄和電子郵件往來中搜尋，你可以直接提出問題，並從你儲存的檔案中獲取答案。

這不能解決什麼問題

為了明確界限：在程式碼版本控制方面，Fabric 並不是 Git 或 Perforce 的替代品。它不會追蹤你 C# 腳本的逐行變更。它不處理合併衝突。它也不會作為版本控制後端整合到 Unity 的編輯器中。

它也不提供離線存取。如果你在飛機上或在沒有網路的地方工作，你需要提前在本地準備好所需的檔案。

它所做的是免除了儲存、整理、搜尋和共享大型二進位資源的負擔，而這些資源正是僅靠 Git 難以管理 Unity 專案的原因。對於許多創意團隊和獨立開發者來說，這正是缺失的那一環。

如果你的 Git 版本庫因為大型資源而變得衝突不斷，且 Perforce 對你的團隊來說顯得架構過於沉重，那麼將程式碼與資源分離是一條實用的折衷之路。讓 Git 專注於它所擅長的事情。為你的資源提供一個合適的雲端歸宿。

常見問題

我可以使用 Fabric 作為 Git LFS 的替代品嗎？

Fabric 不是 Git 的擴充功能，也不會直接整合到 Git 的工作流程中。它是一個獨立的雲端儲存平台。你可以將它與 Git 協同使用：Git 用於你的程式碼，Fabric 用於你的紋理、音訊和模型等大型二進位資源。這完全避免了 Git LFS 的頻寬限制和複雜性。

Fabric 中的檔案可以有多大？

Fabric 能輕鬆處理大型檔案。Unity 專案中常見的檔案類型，包括數百 MB 的紋理圖集、大型 FBX 模型和 WAV 音訊檔案，都在該平台支援的範圍之內。請查看定價頁面以了解當前的儲存方案詳情。

Fabric 支援 Mac 和 Windows 嗎？

是的。Fabric 為這兩個平台都提供了桌面應用程式，同時也提供了行動應用程式。由於 Unity 開發在 Mac 和 Windows 上都會進行，因此這種跨平台支援非常重要。

我的整個團隊可以在 Unity 專案中使用 Fabric 嗎？

是的。Fabric 支援團隊之間的協作。多個團隊成員可以存取、搜尋和批註共享資源。有關團隊方案的詳情，請參閱團隊定價頁面。

Fabric 的雲端串流如何與 Unity 的資源匯入流程協同工作？

Fabric 的雲端硬碟使檔案在你的電腦上顯示為本地檔案。當 Unity 需要匯入資源時，檔案會從 Fabric 的雲端串流傳輸。對於非常大的檔案的首次匯入，這取決於你的網路連接速度。一旦 Unity 匯入並將資源快取到其 Library 資料夾中，後續的載入將使用本地快取。

我的專案數據在 Fabric 中安全嗎？

Fabric 具有備份功能，且私密又安全。你的檔案會加密並安全地儲存在雲端。對於開發未公開專案的遊戲工作室來說，這一點至關重要。

我可以將 Fabric 連結到我已儲存資源的現有 Google Drive 或 Dropbox 嗎？

是的。Fabric 提供與 Google Drive、Dropbox 和其他雲端儲存服務的連結。你可以透過 Fabric 存取這些服務中的檔案，而無需手動移動它們。

那 Unity 的 Plastic SCM (Unity Version Control) 呢？

Unity 自家的版本控制解決方案 Plastic SCM 比 Git 能更好地處理大型檔案。如果你的團隊已經在使用它並且對此感到滿意，那麼將程式碼與資源分離的需求可能就沒那麼迫切。Fabric 仍可作為參考資料、概念藝術、匯出的構建版本以及存在於 Unity 專案本身之外的其他檔案的數位資源管理層。

相關頁面

• 面向開發人員的 Fabric

• 創意資源管理

• 數位資源管理

• 面向工程團隊的 Fabric

• 面向創意團隊的 Fabric

• Fabric 對比 Dropbox

• Fabric 對比 Google Drive

• 審查和批准工作流程