把幾百 GB 的素材檔丟進版本控管，過去十幾年幾乎沒有令人滿意的答案。Git 的設計從一開始就假設檔案是純文字，遇到 PSD、Maya 場景、Substance 材質、未壓縮影音這些動輒幾 GB 的二進位檔，效能會直接崩潰。Git LFS 是補丁，把大檔案外掛到另一個物件儲存上，但隨之而來的是雙重歷史、合作者得額外裝 client、合併衝突沒辦法解、磁碟用量翻倍。Perforce 是業界拿來解這個問題的傳統答案，可是一個 user 席次的訂閱費用一年動輒兩三千美元，二三十人的團隊一年燒掉的金額已經能買下幾臺自家機房的伺服器。
Epic Games 在 2026 年 6 月的 State of Unreal 場合，把內部用了多年的 Lore 用 MIT 授權直接丟上 GitHub。這個系統的前身叫 Unreal Revision Control，原本是 UEFN（Unreal Editor for Fortnite）裡綁定的內建 VCS，Epic 內部跑了好幾年、處理過 Fortnite 規模的素材庫之後，整套挖出來開源——這個動作在版本控管這個多年沒什麼新東西的領域裡，是真正值得認真看的訊號。
設計上跟 Git 走完全不同方向
Git 是分散式的，每個 clone 都拿到完整歷史。這個模型在小型程式碼專案上很漂亮，但對遊戲、影音、CAD、機械學習資料集這類動輒幾百 GB、幾 TB 的工作流，分散式直接失效——沒人會在筆電上塞完整歷史。Lore 從一開始就選了中央化路線，所有資料放在 server，client 跟伺服器要資料，要哪一份拉哪一份。
這個選擇背後有兩個假設。第一是大型團隊本來就需要中央授權跟稽核，分散式信任模型在企業環境裡反而是包袱。第二是內容定址的儲存層做得好，中央化的瓶頸可以靠快取跟去重化解掉，throughput 反而能拉得比分散式高。
Lore 不是只丟出一個 binary 給人用。整個系統把儲存層跟版本控制層切成兩個獨立的子系統：儲存層只負責「給定一段位元組，存進去；給定一個 hash，拿出來」這件事；版本控制層則處理 revision、branch、staging、merge 這些上層概念。兩層用清楚的 API 接起來，意思是儲存層可以單獨被當作一個去重式物件儲存來用，跟版本控制無關。這個切分是 Lore 設計上最值得稱讚的地方。
FastCDC 把大檔案切成可去重的片段
讓 Git LFS 痛苦的核心是它把大檔案當成不可分割的單位。改了一個 byte，整個 blob 都得重傳。Lore 走的是 content-defined chunking 路線：對大檔案套上 FastCDC 這套滾動雜湊演算法，根據資料模式自己找出邊界，把檔案切成大約 64 KiB 一份的片段。
這個切法的關鍵性質是：在檔案開頭插入幾百 KB 資料，後面所有 chunk 的邊界會等比例後移，但原本的 chunk 內容沒變，雜湊值也沒變。意思是版本之間共用的片段，儲存層只存一份。對素材庫常見的「微調貼圖、新增關卡 prefab」這種小幅度更新，去重效率遠勝過整檔重傳。
Lore 也支援 fixed-size chunking 給特定場景用——固定邊界少了 dedup 彈性，但同一段內容永遠對應同一個 chunk address，這對某些做檔案系統 layer 或 snapshot 的下游工具比較友善。每個檔案可以指定要用哪一種策略。
雜湊用的是 BLAKE3，32 byte 輸出。BLAKE3 在 2020 年發布之後，吞吐量在現代 CPU 上明顯領先 SHA-256，多執行緒下優勢更大。Git 還在沿用 SHA-1（雖然有 SHA-256 過渡計畫），這部分 Lore 直接跳過十年的歷史包袱。
不可變儲存跟可變指標切開
Lore 把儲存分成兩個明確角色。不可變儲存層（immutable store）放的是所有檔案 payload、tree node、metadata——任何 byte 寫進去之後就不會被改，靠 BLAKE3 hash 定址，相同內容只存一份。可變儲存層（mutable store）只放「branch 目前指到哪個 revision」「名字對應到哪個 ID」這類經常更新的少量狀態，用 compare-and-swap 確保原子性。
這個切法把一致性的擔憂集中在很小的可變層上，剩下的大量資料是 immutable，可以放心做分散式快取、CDN、冷儲存層級分流。Git 概念類似，但把 packfile 跟 ref 都塞進同一個 repo 結構，分層彈性沒這麼乾淨。
整個 repository 結構是一棵 Merkle tree：檔案 node 雜湊它的內容（小檔案直接雜湊，大檔案雜湊片段 reference 列表）、目錄 node 雜湊它排序過的子節點，根 hash 唯一識別整個 repo 在某個時間點的狀態。差別只在改動的少數節點，沒動的部分自動共用——儲存成本只看「改了什麼」，不看「總共多大」。
稀疏 workspace 是設計初衷而非外掛
UEFN 跟 Fortnite 規模的 repo 不可能整份拉到 client 上。Lore 設計時就把稀疏工作區當成第一公民：workspace 拿到的是 Merkle tree 的根 hash，需要哪個檔案才向 server 要哪個檔案的片段。
更進一步，因為大檔案存的是 fragment reference 列表，每個 reference 帶有 byte offset，client 可以對單一檔案做隨機讀取——拿前 1 MB 看 metadata 不必下載整檔。這對縮圖預覽、二進位 diff、線上串流這類工具場景很有意義，是 Git LFS 永遠做不到的事。
Partition 是另一個重要設計。每個 partition 有一個 16 byte 識別碼，session 綁定 partition，沒授權的 partition 就算知道內容 hash 也拿不到資料。底層儲存仍然在 partition 之間去重，但去重不會變成 side channel 洩漏存取權限。多租戶部署可以放心共用實體儲存。
CLI、SDK 跟可以怎麼接
CLI 工具叫 lore，安裝指令是一個 shell script，本地端開 demo 模式可以在不開 server 的情況下直接玩。常見指令的形狀對熟 Git 的人不會太陌生——lore init、lore add、lore commit、lore branch、lore checkout 都在，但底層運作完全不一樣。commit 在 Lore 裡是真正不可變的，靠 chain 的密碼學完整性串起來；branch 只是 mutable store 裡的一個指標，建立跟切換的成本接近於零。
Epic 同時釋出 JavaScript、Python、C#、Go、Rust、C/C++ 的 SDK。這個語言覆蓋面在 VCS 領域很罕見，背後意圖很明確：希望 Lore 不只是被人類用，也被 build pipeline、CI 系統、editor 外掛、asset processor 大量整合進去。
部署層面，Lore 的儲存後端有定義好的 backend interface，預設實作走本地檔案系統，但介面本身設計成可以接到 S3 相容物件儲存、自家機房的硬碟陣列、或自寫的 backend。協定跟資料格式都跟實作分開發布，第三方寫一個獨立的 server 端可以跟官方 client 互通——這跟 Git 多年來實作各自為政、protocol 半文件化的狀況有本質差異。
哪些團隊現在就應該開始評估
Lore 在 2026 年中還是 pre-1.0，protocol 跟 CLI 都有可能調整，正式拿來當生產 VCS 用要做好跟著版本升級走的準備。但有幾個場景值得現在就去摸：
遊戲工作室如果已經吃 Git LFS 的虧很久——repo 大到 clone 一次要喝杯咖啡、合作者忘記裝 LFS hook 就推爛了 server、跨地區同步靠人工搬硬碟——Lore 的稀疏拉取跟片段去重是直接對症的解法。
機械學習團隊維護資料集版本的場景也很相似。DVC、Git LFS、自寫的 S3 加 manifest 各有各的缺陷，Lore 把版本控管跟物件儲存的職責同時收進來，是個還沒有人在這個方向實作過的選項。
工程組織內部需要管 Figma 設計檔、影音素材、CAD 檔案的 design ops 場景，Lore 的中央化模型加上 partition 隔離，比硬塞進 Git 的方案乾淨。
純程式碼專案則沒有立刻換的必要。Git 在純文字場景仍然是最成熟、生態最完整的選擇，Lore 也沒有要打這個市場。一個 repo 同時有大量素材跟程式碼的場景，目前比較合理的做法是程式碼留在 Git、素材走 Lore，靠 build script 在 CI 階段串起來。
自架版本控管這條路
Lore 的儲存特性決定了它對伺服器規格的需求：磁碟容量跟頻寬比 CPU 跟 RAM 更關鍵。一臺中等規格的 VPS 加上夠用的 NVMe 容量，就能起一個內部團隊規模的 Lore 伺服器；如果素材庫真的拉到 TB 等級，再考慮把 backend 接到自家機房的儲存陣列。NCSE Network 在臺灣是方電訊機房提供搭載 Intel Gold CPU 與 NVMe SSD 的 VPS 主機，也支援機房代管，跑自架 Lore server、Forgejo、或其他開發團隊內部服務，從頻寬到延遲條件都穩得住。
