本篇文章更新時間：2026/03/23
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
Manyana：重新想像版本控制的未來
以 CRDT 為核心，打造不再「合併失敗」的世界
編輯前言：這篇文章來自 Bram Cohen（BitTorrent 創辦人）在其部落格的介紹：Manyana。它提出一種以 CRDT 為核心的版本控制新模型，完整挑戰 Git 這類傳統 VCS 長年以來的痛點。對於工程師、協作工具開發者，這篇文章可以說是未來十年的技術藍圖。
核心觀點 (Key Takeaways)
- CRDT 是版本控制的下一步：許多問題不是技術做不到，而是 UX 尚未被解決；Manyana 提供了一個具體的解法。
- 合併永不失敗，但依然有「可讀的衝突」：CRDT 保證不會出現傳統意義上的 merge conflict，但仍能精準呈現對應的變動關係。
- 歷史直接存在於資料結構本身：不再依賴 Git 式的 DAG 推算祖先，而是以「weave」方式保存所有歷史，讓 rebase 也能保留真實軌跡。
深入解析
來源文章：Manyana
CRDT（Conflict-Free Replicated Data Type）一直被視為協作系統的強大基礎，但近年卻少見有人將它用於版本控制。Bram Cohen 認為，技術早就成熟，只是過去缺乏好的 UX 設計，而 Manyana 的目的，就是把這個缺口補起來。
更「可讀」的衝突呈現
傳統 Git 在面對某些情境下的合併衝突會產生不透明的差異。例如，兩個人同時編輯一個 function：
- 一個人把 function 刪掉
- 另一個人在其中插入一行 log
Git 給你的通常是兩大團不知所云的 blob，需要工程師自己「逆向推理」到底發生了什麼。
Manyana 則把 CRDT 的資訊完整呈現，讓每一段差異都能精準指出「誰、對什麼、做了什麼」：
Each section tells you what happened and who did it. Left deleted the function. Right added a line in the middle.
透過這種方式，衝突不是阻礙，而是資訊本身。
合併永不失敗，順序永久固定
CRDT 的特點之一是「eventual consistency」。不論你用什麼順序合併，每次結果都一致。
這直接帶來兩個突破：
- 合併永遠成功，衝突只是 metadata
- 插入點的順序一旦確立，就不會因為不同人合併順序不同而造成差異
這解決了 Git 在多人分支時容易出現的「非決定性」問題。
歷史存在於資料結構，不需回推 DAG
Manyana 採用的是一種「weave」結構，也就是把所有出現過的行全部納入同一資料結構中，並附上新增、移除的 metadata。
這意味著：
- 合併不需要找 common ancestor
- 不會有「DAG 太複雜導致 3-way merge 失效」的問題
作者更提出一個重要觀點：rebase 不需要摧毀歷史。只要給 commit 一個「primary ancestor」註記，就能完整記錄真實演化，同時達成 rebase 想達到的效果。
筆者心得與啟發
老實說，看完 Manyana 的介紹，我最大的感受是：版本控制這件事其實還遠遠沒有被做完。
我們已經習慣 Git 那些令人頭痛的體驗，包括：
- 衝突解析難讀
- rebase 破壞歷史
- merge 有時會出現模糊的結果
- 多人編輯時的非決定性問題
Manyana 把上述問題視為「不是必然的」，而是「技術選擇問題」。如果 CRDT 一開始就是版本控制的主流，我們今天的協作體驗可能完全不同。
特別讓我印象深刻的是作者提到的：
The history is in the weave, not reconstructed from the DAG.
這句話不只是在描述資料結構，也是一種哲學——版本控制不該靠猜測，而應該是完整記錄。
雖然 Manyana 只是 470 行 Python 的 demo，但它成功證明：
- CRDT 不是沒辦法做版本控制
- 關鍵在於 UX，而 Manyana 展示了可行的方向
如果未來真的有人基於這套思想打造一款主流工具，我想 Git 的未來地位不一定無可撼動。
對協作工具、雲端 IDE、甚至生成式 AI 程式工具來說，CRDT-based VCS 會是非常值得關注的下一步。